Análisis automático de obligaciones y derechos en acuerdos de cliente

TRABAJO FIN DE M´ ASTER An´alisis autom´atico de obligaciones y derechos en acuerdos de cliente Realizado por Mar´ıa Elena Molino Pe˜na Para la obtenci´on del t´ıtulo de M´aster en Ingenier´ıa del Software: Cloud, Datos y Gesti´on TI Dirigido por Jos´e Mar´ıa Garc´ıa Rodr´ıguez y Antonio Ruiz Cort´es Convocatoria de septiembre, curso 2022/23 Agradecimientos Gracias a mi familia y amigos, por su apoyo constante. Gracias a Jos´e Mar´ıa y Antonio, por sus valiosos consejos. Gracias a la vida, por permitirme estar donde estoy. Este trabajo ha sido apoyado parcialmente por las siguientes subvenciones: PID2021- 126227NB-C21, PID2021-126227NB-C22, TED2021-131023B-C21, y PDC2022-133521- I00 que est´an financiadas por MCIN/AEI/10.13039/501100011033 y “ERDF a way of making Europe”; y la beca PYC20 RE 084 US, que est´a financiada por Junta de Andaluc´ıa/ERDF,UE. i Resumen Los acuerdos de clientes est´an formados por un conjunto de documentos legales que recogen los t´erminos y condiciones relacionados con la adquisici´on y el uso de los servicios que proporciona el proveedor. Estos son la base para proteger los intereses de las partes y act´uan como un recurso esencial para remedios legales, indemnizaciones o la terminaci´on del contrato, entre otros aspectos. A pesar de la importancia que tiene el contrato en la relaci´on comercial entre las partes implicadas, el an´alisis autom´atico del mismo es un campo de investigaci´on que requiere una mayor exploraci´on. Adem´as, existe gran inter´es en el desarrollo de un sistema inform´atico capaz de gestionar todo el ciclo de vida de los contratos, desde su creaci´on hasta su finalizaci´on. La mayor´ıa de las aproximaciones en este ´ambito se dedican principalmente a la extracci´on autom´atica o semiautom´atica de informaci´on espec´ıfica de los mismos. Algunas, por otro lado, se centran en el razonamiento sobre esta informaci´on, ofreciendo respuestas a una variedad de preguntas. A pesar de los resultados prometedores de estas propuestas, la mayor´ıa de ellas presentan limitaciones, ya sea en la t´ecnica empleada para extraer la informaci´on o en la falta de desarrollo de un sistema f´acilmente usable por las partes involucradas. En este trabajo, se propone un enfoque basado en la detecci´on de oraciones que indican obligaci´on o derecho para alguna de las partes involucradas en el acuerdo, as´ı como la identificaci´on de los responsables de cumplir con cada una de estas cl´ausulas detectadas. El objetivo de extraer esta informaci´on es facilitar a las partes la comprensi´on del acuerdo y la reflexi´on sobre el mismo. Para automatizar este proceso se desarrolla el sistema iCan, que mediante el uso de modelos de lenguaje grandes es capaz de identificar esta informaci´on del acuerdo. En concreto, la propuesta recibe como entrada un acuerdo en lenguaje natural y devuelve un conjunto de obligaciones, derechos y actores. La evaluaci´on del sistema se realiza comparando los resultados obtenidos al analizar autom´aticamente el acuerdo a nivel de servicio de la compa˜n´ıa Digital Realty con diferentes herramientas. Las conclusiones derivadas de los resultados reflejan que iCan es capaz de detectar las obligaciones y derechos mejor que el modelo de lenguaje Chat GPT y el marco de trabajo desarrollado por Natalona et al. [15] en base al criterio de evaluaci´on definido. Logrando identificar el 100 % de las obligaciones detectadas manualmente y 3 de los 4 derechos, adem´as con una mayor precisi´on y exhaustividad que el resto de las aproximaciones. Palabras clave: Acuerdos de cliente, An´alisis autom´atico, Modelos de lenguaje, Detecci´on de obligaciones y derechos ii Abstract Customer agreements are composed of a set of legal documents that contain the terms and conditions related to the acquisition and use of the services provided by the supplier. These are the basis for protecting the interests of the parties and act as an essential resource for legal remedies, indemnification or termination of the contract, among other aspects. In spite of the relevance of the contract in the business relationship between the parties involved, the automatic analysis of the contract is a field of research which requires further exploration. In addition, there is high interest in the development of a system capable of managing the entire life cycle of contracts, from their creation to their termination. Most approaches in this area address the automatic or semiautomatic extraction of specific information from them. However, others focus on the reasoning of this information, providing answers to various questions. Despite the promising results of these proposals, most of them have limitations, either in the technique they use to extract the information, or even in the lack of development of a system easily usable by the parties involved. In this work, we propose an approach based on the detection of sentences that indicate obligation or right for any of the parties involved in the agreement, as well as the identification of those responsible for compliance with any of the clauses detected. In order to facilitate the understanding and reasoning of the agreement to the parties. Therefore, to automate this process we developed a system called iCan, which using large language models has the ability to identify this information from the agreement. In fact, the proposal receives an agreement as input and returns the set of obligations, rights and actors. The evaluation of the system is performed by comparing the results obtained by different tools when automatically analyzing the service level agreement of the Digital Realty company. The conclusions from the results show that iCan is better than the Chat GPT model language and the framework developed by Natolana et al. [15] by detecting the obligations and rights using our evaluation criteria. ICan manages to identify 100 % of the manually detected obligations and 3 out of 4 rights, also reaching a greater precision and recall than the other approaches. Keywords: Customer agreements, Automatic analysis, Language models, Detection of obligations and rights iii ´ Indice general 1. Introducci´on 1 1.1. Introducci´on................................. 1 1.2. Contexto................................... 2 1.3. Motivaci´on.................................. 3 1.4. Descripci´on del problema . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.1. Ejemplificaci´on del problema de clasificaci´on . . . . . . . . . . . 6 1.5. Objetivos .................................. 10 1.6. Contribuciones ............................... 10 1.7. Estructura de este documento . . . . . . . . . . . . . . . . . . . . . . . 11 2. Estudio previo 12 2.1. Introducci´on................................. 12 2.2. Metodolog´ıa................................. 12 2.3. Planificaci´on................................. 13 2.4. Conclusiones................................. 14 3. Materias relacionadas 15 3.1. Introducci´on................................. 15 3.2. AcuerdosdeCliente............................. 15 3.2.1. Proveedores en la nube . . . . . . . . . . . . . . . . . . . . . . . 18 3.3. An´alisis autom´atico de contratos . . . . . . . . . . . . . . . . . . . . . 22 3.3.1. An´alisis autom´atico de SLAs . . . . . . . . . . . . . . . . . . . . 29 3.3.2. An´alisis autom´atico con l´ogica de´ontica . . . . . . . . . . . . . . 32 3.4. Procesamiento de Lenguaje Natural (NLP) . . . . . . . . . . . . . . . . 34 3.4.1. Arquitectura Transformer . . . . . . . . . . . . . . . . . . . . . 35 3.4.2. Aprendizaje por transferencia . . . . . . . . . . . . . . . . . . . 38 3.4.3. Prompt Engineering . . . . . . . . . . . . . . . . . . . . . . . . 40 3.5. Resumen y conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4. Descripci´on de la propuesta 43 4.1. Introducci´on................................. 43 4.2. Propuesta de soluci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.1. Identificaci´on de obligaciones y derechos . . . . . . . . . . . . . 45 4.2.2. Detecci´on del sujeto . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2.3. Razonamiento autom´atico . . . . . . . . . . . . . . . . . . . . . 57 4.2.4. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . 58 4.2.5. iCan................................. 59 4.3. Retos..................................... 62 4.4. Conclusiones................................. 62 5. Validaci´on 64 5.1. Introducci´on................................. 64 5.2. An´alisis del SLA de Digital Realty . . . . . . . . . . . . . . . . . . . . 64 iv 5.2.1. ChatGPT.............................. 66 5.2.2. Marco sem´antico para automatizar los SLAs en la nube . . . . . 69 5.2.3. iCan................................. 71 5.2.4. Comparativa de resultados . . . . . . . . . . . . . . . . . . . . . 72 5.3. Amenazas a la validez . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.4. Conclusiones................................. 74 6. Conclusiones y trabajo futuro 75 7. Bibliograf´ıa 77 A. Documentos anexados 81 A.1. Anexo I: Instrucciones clasificaci´on . . . . . . . . . . . . . . . . . . . . 82 A.2. Anexo II: SLA de Digital Realty . . . . . . . . . . . . . . . . . . . . . . 87 v ´ Indice de figuras 1.1. Tweet sobre la posibilidad de utilizar ChatGPT en el contexto de CAs [31] 4 1.2. Ejemplomotivador ............................. 4 1.3. Extracto 1. SLA de AWS EC2 . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Extracto 2. SLA de AWS EC2 . . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Extracto 3. SLA de AWS EC2 . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Ciclometodol´ogico ............................. 12 2.2. Planificaci´onideal.............................. 13 2.3. Evoluci´on de la planificaci´on . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Estructura l´ogica del CA [32] ....................... 17 3.2. Estructura del CA de Rackspace [34] y GitHub [16] ........... 17 3.3. Extracto del sitio web “Claudette” . . . . . . . . . . . . . . . . . . . . 23 3.4. Extracto del sitio web “Phoenix” . . . . . . . . . . . . . . . . . . . . . 24 3.5. Extracto del sitio web “Term Scout” . . . . . . . . . . . . . . . . . . . 25 3.6. Respuesta sobre el CA de Amazon . . . . . . . . . . . . . . . . . . . . 26 3.7. An´alisis del SLA de AWS EC2 . . . . . . . . . . . . . . . . . . . . . . . 27 3.8. Arquitectura Transformer. Figura obtenida del art´ıculo Vaswani et al. [44] 36 3.9. Ciclo iterativo sobre el desarrollo de prompt ............... 41 4.1. Etapas del sistema iCan . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2. Proceso para la obtenci´on de los datasets . . . . . . . . . . . . . . . . . 45 4.3. Etiquetado de cl´ausulas con MAXQDA . . . . . . . . . . . . . . . . . . 47 4.4. N´umero de oraciones por categor´ıa . . . . . . . . . . . . . . . . . . . . 48 4.5. Total de obligaciones y derechos por actor . . . . . . . . . . . . . . . . 49 4.6. Resultados de las etapas de la adaptaci´on del modelo . . . . . . . . . . 52 4.7. Diferencia en la representaci´on del modelo base y el modelo entrenado . 52 4.8. Esquema para la detecci´on del actor . . . . . . . . . . . . . . . . . . . . 53 4.9. Arquitectura del sistema iCan . . . . . . . . . . . . . . . . . . . . . . . 59 4.10. P´agina inicial iCan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.11. Formulario para a˜nadir un nuevo acuerdo . . . . . . . . . . . . . . . . . 60 4.12. An´alisis del acuerdo y posibilidad de identificar los sujetos . . . . . . . 61 4.13.ResultadosdeiCan............................. 61 5.1. Resultado de la identificaci´on manual . . . . . . . . . . . . . . . . . . . 66 5.2. Resultado de la identificaci´on por Chat GPT . . . . . . . . . . . . . . . 69 5.3. Resultado de la identificaci´on por el framework de Natolana . . . . . . 70 5.4. Resultado de la identificaci´on por iCan . . . . . . . . . . . . . . . . . . 71 5.5. Comparativa entre los positivos correctos y los valores detectados . . . 72 5.6. Comparativa entre el n´umero de cl´ausulas detectadas correctamente . . 73 5.7. Comparativa entre el n´umero de actores identificados correctamente . . 73 vi ´ Indice de extractos de c´odigo 4.1. Prompt empleado para la identificaci´on del sujeto . . . . . . . . . . . . 54 4.2. Respuesta del modelo GPT-3.5 turbo . . . . . . . . . . . . . . . . . . . 55 5.1. Prompt utilizado para interactuar con Chat GPT . . . . . . . . . . . . 67 5.2. Respuesta reducida del Chat GPT . . . . . . . . . . . . . . . . . . . . . 67 vii 1. Introducci´on 1.1. Introducci´on Las empresas de ingenier´ıa suelen externalizar parte de la gesti´on y almacenamiento de su infraestructura en servicios en la nube, lo que las expone a una serie de riesgos en t´erminos de seguridad, p´erdida de propiedad de la informaci´on, interrupciones en la continuidad del negocio y otros desaf´ıos asociados. Para mitigar estos riesgos, es crucial asegurarse de las condiciones que ofrecen los proveedores y verificar que cumplen con las cl´ausulas estipuladas en el Acuerdo de Cliente (m´as conocidos como Customer Agreement o CA) que gobierna los servicios en la nube. Los CAs recogen los t´erminos y condiciones relacionados con la adquisici´on y el uso de los servicios. Estos son la base para proteger los intereses de las partes y act´uan como un recurso esencial para remedios legales, indemnizaciones o cese del contrato. Adem´as, en ellos se especifica informaci´on cr´ıtica para el negocio del cliente como el uso aceptable de los servicios, la seguridad de los datos, la propiedad intelectual, la disponibilidad esperada de los servicios, las compensaciones por incumplimiento y, los derechos y responsabilidades de las partes [40]. A pesar de la importancia que presenta el acuerdo en el ecosistema de la computaci´on en la nube, actualmente no existen medios eficientes para comprender f´acilmente las condiciones establecidas por los proveedores. De hecho, el CA suele estar dividido en varios documentos que utilizan un lenguaje con t´erminos legales poco comprensibles para la mayor´ıa de las personas. Esto supone un coste para la empresa, pues requieren un mayor n´umero de profesionales especializados para analizar todos sus contratos externos. Adem´as, al ser una tarea mayoritariamente manual y dada la heterogeneidad en el contenido de los acuerdos de cada proveedor, su an´alisis suele ser tedioso, suponer grandes cantidades de tiempo y propenso a errores. Como resultado, las empresas no pueden garantizar que lo que est´an firmando realmente beneficie a su negocio o no. Es por esta raz´on que existe un gran inter´es en la automatizaci´on del an´alisis de CAs. Esto quiere decir disponer de un sistema inform´atico que pueda realizar o facilitar la creaci´on y revisi´on de los acuerdos. Estos sistemas se pueden desarrollar mediante la aplicaci´on de una variedad de t´ecnicas, incluyendo el Procesamiento de Lenguaje Natural (en ingl´es NLP). Estas t´ecnicas posibilitan la comprensi´on del texto de los acuerdos y la capacidad de proporcionar respuestas bien fundamentadas a preguntas espec´ıficas. Para ayudar al an´alisis de los acuerdos encontramos soluciones comerciales como Term Scout [30]. Esta herramienta act´ua como un repositorio de t´erminos y condiciones de diferentes servicios, los cuales han sido evaluados en funci´on de un conjunto predefinido de preguntas que proporcionan informaci´on relevante sobre los mismos. Sin embargo, es importante tener en cuenta que esta soluci´on presenta algunas limitaciones. Por ejemplo, eval´uan los acuerdos utilizando ´unicamente un conjunto fijo de 30 preguntas. 1 •Tipo: obligaci´on. Actor: Amazon. Justificaci´on: Amazon tiene la obligaci´on de no cobrar por una instancia que est´e indisponible m´as del 10 % de una hora. Procedemos con el an´alisis del segundo fragmento de texto del acuerdo, que se muestra en la Figura 1.4. Figura 1.4: Extracto 2. SLA de AWS EC2 A continuaci´on, se presenta la clasificaci´on de las declaraciones detectadas: S6: “We will apply any Service Credits only against future payments for Amazon EC2 otherwise due from you.” •Tipo: derecho. Actor: Amazon. Justificaci´on: Amazon tiene el derecho a aplicar los cr´editos en pagos futuros. S7: “We may issue the Service Credit to the credit card you used to pay for the billing cycle in which the Unavailability occurred.” •Tipo: derecho. Actor: Amazon. Justificaci´on: Amazon tiene el derecho a enviar los cr´editos a la tarjeta que se usa para el pago de las cuotas. S8: “Service Credits will not entitle you to any refund or other payment from AWS” •Tipo: obligaci´on. Actor: cliente. Justificaci´on: el cliente tiene la obligaci´on de abstenerse de reclamar o exigir compensaciones adicionales a los cr´editos que AWS le proporciona. S9: “Service Credits may not be transferred or applied to any other account.” •Tipo: obligaci´on. Actor: cliente. Justificaci´on: el cliente tiene la obligaci´on de no transferir los cr´editos. S10: “You must submit a claim by opening a case in the AWS Support Center.” 8 •Tipo: obligaci´on. Actor: cliente. Justificaci´on: el cliente est´a obligado a enviar una solicitud para poder recibir los cr´editos. S11: “You may only submit a claim under either the Region-Level SLA or the Instance-Level SLA” •Tipo: derecho. Actor: cliente. Justificaci´on: el cliente solo tiene el derecho a solicitar un cr´edito. S12: “Your credit request must be received by us by the end of the second billing cycle after which the incident occurred” •Tipo: derecho. Actor: Amazon. Justificaci´on: el cliente tiene la obligaci´on de entregar la solicitud en tiempo y por tanto, el proveedor tiene el derecho a recibirla. S13: “We will issue you a Service Credit within one billing cycle following the month in which your request is confirmed by us.” •Tipo: obligaci´on. Actor: Amazon. Justificaci´on: Amazon tiene la obligaci´on de conceder el cr´edito si la solicitud es valida. Estudiamos el ´ultimo fragmento de texto del acuerdo, figura 1.5. Se detecta que no dispone de oraciones que describan acciones obligatorias o de derecho para ninguna de las partes involucradas. Esto se debe a que las secciones de exclusiones y definiciones generalmente no indican acciones, sino hechos o t´erminos espec´ıficos. Figura 1.5: Extracto 3. SLA de AWS EC2 Como se puede observar, esto es solo la exploraci´on de las obligaciones y derechos en el SLA de uno de los servicios proporcionado por AWS contando con m´as de 200. Adem´as, los acuerdos de cliente cuentan con multitud de documentos que tambi´en tendr´ıan que tenerse en cuenta si deseamos analizar el acuerdo completo. Concluir por tanto, que el an´alisis manual de CAs es costoso en t´erminos de tiempo, adem´as la clasificaci´on de cl´ausulas en ocasiones puede generar dudas, como la S12 que claramente 9 describe una obligaci´on para el cliente, pero el agente de la oraci´on es el proveedor, es decir, la acci´on de recibir la solicitud de cr´edito debe ser realizada por el receptor o destinatario de la solicitud, que en este caso ser´ıa el proveedor al que se dirige la solicitud de cr´edito. Por esta raz´on, entre otras, existe el deseo de automatizar la clasificaci´on de cl´ausulas en la medida de lo posible. 1.5. Objetivos El desarrollo de este trabajo tiene por objetivo principal la extracci´on y an´alisis sobre informaci´on relevante contenida en los CA, de manera que se pueda proporcionar una soluci´on a los dos problemas mencionado anteriormente: clasificaci´on de cl´ausulas y an´alisis de la informaci´on del acuerdo. Para lograr este objetivo, se plantean una serie de objetivos espec´ıficos que se detallan a continuaci´on: Definir un modelo para detectar las obligaciones y derechos de los acuerdos. Extraer autom´aticamente las cl´ausulas que indican obligaci´on o derecho. Detectar el actor que debe o tiene la posibilidad de realizar la acci´on que se indica en la cl´ausula. Proponer un conjunto de operaciones de an´alisis que permitan razonar sobre la informaci´on del acuerdo. Evaluar y comparar el comportamiento de nuestra soluci´on con respecto a las soluciones existentes en el “estado del arte”. 1.6. Contribuciones Este trabajo contribuye al avance de la l´ınea de investigaci´on de ingenier´ıa de servicios, en concreto en el ´area de CAs. Sin embargo, para lograr una contribuci´on significativa en este campo de investigaci´on, es crucial examinar el estado del arte en otras disciplinas, como el procesamiento de lenguaje natural y la l´ogica de´ontica. Las aportaciones que se presentan y que est´an disponibles para el uso de otros investigadores son las siguientes: Reflexi´on sobre las obligaciones y derechos en los CAs y exploraci´on de las t´ecnicas existentes para extraer y analizar la informaci´on relevante de estos acuerdos. Criterio para la clasificaci´on manual de obligaciones y derechos en SLAs. Conjunto de datos de obligaciones y derechos destinado a entrenamiento, evaluaci´on y prueba del modelo. Modelos entrenados mediante el uso de aprendizaje supervisado, utilizando el conjunto de datos previamente mencionado. Sistema que permite la extracci´on autom´atica de las obligaciones y derechos de un acuerdo y el actor que debe realizar la acci´on. 10 Este trabajo queda parcialmente respaldado con las siguientes publicaciones: Molino-Pe˜na, Elena, Garc´ıa, Jos´e Mar´ıa, Ruiz-Cort´es, Antonio. Operaciones de An´alisis sobre los T´erminos de Uso en Customer Agreements. In: Proc. XVII Jornadas de Ingenier´ıa de Ciencia e Ingenier´ıa de Servicios. SISTEDES (2022). Molino-Pe˜na, Elena, Garc´ıa, Jos´e Mar´ıa, Ruiz-Cort´es, Antonio. Limitations of current techniques to detect Obligations and Rights in SLA. In: Proc. XVIII Jornadas de Ingenier´ıa de Ciencia e Ingenier´ıa de Servicios. SISTEDES (2023). 1.7. Estructura de este documento El resto del documento sigue la siguiente estructura: en el cap´ıtulo 2se presenta el marco metodol´ogico seguido, as´ı como la planificaci´on prevista. En el cap´ıtulo 3se recoge el marco te´orico necesario para el desarrollo del trabajo, incluyendo los avances en la automatizaci´on de contratos y los conocimientos relacionados con la l´ogica de´ontica y el NLP que podr´ıan resolver el problema planteado. En el cap´ıtulo 4se detallan los aspectos de dise˜no e implementaci´on de la propuesta presentada. En el cap´ıtulo 5se muestra el proceso de validaci´on de la propuesta. Finalmente, en el ´ultimo cap´ıtulo se presentan las conclusiones del trabajo y se exponen las l´ıneas futuras de investigaci´on. 11 2. Estudio previo 2.1. Introducci´on Este cap´ıtulo se dedica a exponer los aspectos destacados sobre la gesti´on temporal y de recursos antes y durante el desarrollo de este trabajo, as´ı como los posibles desaf´ıos que hemos afrontado debido al proceso de aprendizaje. En concreto, en las pr´oximas secciones, se detallan la metodolog´ıa que seguimos para alcanzar nuestros objetivos, as´ı como la planificaci´on que define el proceso de trabajo necesario para cumplir con las expectativas previstas. 2.2. Metodolog´ıa El proceso metodol´ogico seguido para el desarrollo de este trabajo consta de cinco fases, las cuales est´an representadas en la figura 2.1. Se presenta en forma de ciclo, ya que no se trata de un proceso estrictamente secuencial. A pesar de seguir los pasos en orden, hemos realizado varias etapas y ejecutado varias fases seg´un las demandas del trabajo. Durante todo este proceso iterativo, se ha contado con la participaci´on activa de los tutores del proyecto. Se manten´ıan reuniones semanales regulares en las que se presentaban los avances realizados y se defin´ıan los pr´oximos pasos a seguir. 12 3 4 5 OBJETIVOS Y PROTOTIPADO SOLUCIONES EXISTENTES Y ALTERNATIVAS DE SOLUCIÓN EVALUACIÓN DISEÑO E IMPLEMENTACIÓN PROBLEMA Y MOTIVACIÓN Figura 2.1: Ciclo metodol´ogico Nuestro primer paso en la investigaci´on fue definir el problema de la manera m´as precisa posible, asegur´andonos de comprender claramente todos los aspectos a abordar. Por otro lado, tambi´en, cuestionamos si era de inter´es dar soluci´on a esta problem´atica. Tras tener relativamente claro el problema, profundizamos en la definici´on de los objetivos del trabajo. Adem´as, creamos un prototipo no funcional a modo de visualizar a alto nivel las expectativas esperadas. 12 En este punto, exploramos propuestas existentes en este ´area, centr´andonos especialmente en los enfoques de soluci´on utilizados. Tambi´en, consideramos otras alternativas tecnol´ogicas que pudieran dar una soluci´on m´as eficiente al problema descrito. Posteriormente, realizamos un primer dise˜no e implementaci´on del sistema a modo de prueba de concepto, con el fin de evaluar la viabilidad de la propuesta. El artefacto resultante se eval´ua mediante la comprobaci´on de los resultados que obtiene, y en funci´on de ello decidimos si estamos en el enfoque correcto y qu´e pasos debemos tomar a continuaci´on. Si es necesario, ajustamos o refinamos el problema o algunas de las fases del ciclo. 2.3. Planificaci´on La planificaci´on de un proyecto de investigaci´on es una tarea compleja, pues esta busca proporcionar respuestas o enfoques de soluci´on a problemas poco estudiados o que las aproximaciones conocidas no han logrado abordar adecuadamente, entre otros posibles aspectos. Por lo tanto, durante el desarrollo de un trabajo de investigaci´on suelen surgir imprevistos fuera del alcance de los investigadores, debido al tiempo que conlleva asentar nuevos conceptos y la facilidad de equivocarse en el trayecto. Durante este proceso, debemos enfrentarnos a multitud de desaf´ıos como por ejemplo, definir correctamente el problema que se desea abordar o encontrar alternativas que resuelvan estos problemas de manera eficiente, as´ı como ser capaz de concretar el conocimiento adquirido en un software funcional. 211 312 41 5 Formación CAs y alternativas Propuesta de solución Formación Transformers Implementación (datos y entrenamiento) Evaluación artefacto 2023 Memoria TFM Presentación 10 2022 6 T A R E A S Definición del problema Figura 2.2: Planificaci´on ideal A lo largo del desarrollo de este trabajo, nos hemos enfrentado a diversos obst´aculos que nos han llevado a modificar la problem´atica original. Adem´as, durante el proceso 13 de desarrollo, ha sido necesario ajustar la definici´on del problema en varias ocasiones, realizar varias revisiones al material relacionado, profundizando en las t´ecnicas de desarrollo y modificar la implementaci´on. Todo este proceso de aprendizaje ha guiado nuestra investigaci´on hacia los resultados que presentamos en este TFM. Realizar un progreso secuencial es idealmente la manera m´as ´optima de resolver las tareas que nos proponemos, como se observa en la figura 2.2 que representa la planificaci´on inicial e ideal del desarrollo del proyecto. El hecho es que como humanos cometemos errores y en multitud de ocasiones debemos volver al inicio o rehacer parte del trabajo. Es por ello, que durante el desarrollo de este TFM ha sido necesario realizar modificaciones en la planificaci´on, resultando en un proceso similar al que se observa en la figura 2.3. sep - oct nov - dic may - jun jul - ago sep Formación CAs Alternativas de automatización ene - feb mar - abr Cambio de problemática Definición del problema Definición problema y prototipado Implementación Formación Transformers Formación Transformers Evaluación Definición del problema Alternativas de automatización Implementación Propuesta de solución Implementación Evaluación Formación Transformers Redacción memoria Redacción memoria Presentación Implementación Definición del problema y solución Propuesta de solución Figura 2.3: Evoluci´on de la planificaci´on 2.4. Conclusiones En este cap´ıtulo, se han abordado de manera general los aspectos relacionados con la gesti´on del tiempo, los recursos, las responsabilidades y las problem´aticas del presente trabajo. A modo de conclusi´on en cuanto al desarrollo del TFM, es relevante resaltar la importancia de aprender de cada uno de los errores cometidos y disfrutar del proceso de aprendizaje. 14 3. Materias relacionadas 3.1. Introducci´on La contrataci´on de servicios en el ´ambito empresarial es fundamental para delegar tareas a empresas especializadas. Para garantizar legalmente esta relaci´on son esenciales los contratos que definen las condiciones del servicio que se va a proporcionar. En el contexto de servicios en la nube, los compromisos entre las partes se realizan a trav´es de CAs, que contienen cada vez m´as cantidad de informaci´on, incluyendo aspectos legales y normativas actualizadas. Analizar estos acuerdos, comprender todas sus cl´ausulas y comparar condiciones con otros proveedores son tareas complejas que obstaculizan la contrataci´on de nuevos servicios. Existen soluciones parciales que facilitan la extracci´on de cl´ausulas abusivas, as´ı como aquellas que sugieren derecho u obligaci´on. Adem´as, tanto investigadores como empresas comerciales proponen operaciones de an´alisis para facilitar el razonamiento sobre la informaci´on contenida en los acuerdos. Aun as´ı, los avances en t´ecnicas de NLP y aprendizaje profundo pueden significativamente mejorar la eficiencia y precisi´on del an´alisis autom´atico de CAs. En este cap´ıtulo, se presentar´a una descripci´on de los acuerdos de cliente, as´ı como los avances conocidos hasta la fecha y sus limitaciones, destacando su utilidad en nuestra investigaci´on (secci´on 3.2). Tambi´en se proporcionar´a informaci´on sobre los acuerdos de cliente de diferentes proveedores en la nube que ser´an empleados en el sistema a desarrollar. A continuaci´on, se estudiar´an diferentes enfoques que pretenden automatizar el an´alisis autom´atico de contratos en todos sus aspectos y, se explorar´a la l´ogica de´ontica como una posible soluci´on para etiquetar correctamente las oraciones del acuerdo seg´un el estado que indican (secci´on 3.3). Finalmente, se abordar´an los avances en el NLP que pueden mejorar la extracci´on de informaci´on del acuerdo y servir como posible soluci´on para la clasificaci´on de cl´ausulas (secci´on 3.4). 3.2. Acuerdos de Cliente La contrataci´on de un servicio, en particular los servicios en la nube, implica generalmente un acuerdo entre el cliente y el proveedor relativo a la adquisici´on y el uso de los servicios, denominado CA. Estos acuerdos suelen estar compuestos por uno o varios documentos que establecen los t´erminos y condiciones que regulan el uso de los servicios. En la actualidad, no existen reglas espec´ıficas que dictaminen qu´e contenido debe incluirse en cada una de las partes que forman el acuerdo. Esto implica que algunos aspectos pueden no estar cubiertos en un solo documento. A pesar de ello, se espera que en el principal se haga referencia a todos los dem´as que deben ser aplicados [40]. Cuando un cliente se suscribe, contrata o adquiere un servicio, el correspondiente CA se convierte en el contrato entre las partes, por lo que llamarlo acuerdo puede 15 considerarse un eufemismo. En este sentido, de acuerdo con el Reglamento Europeo 593/2008 sobre la ley aplicable a las obligaciones contractuales, este CA tiene fuerza legal. Esto quiere decir, que este compromiso formal realizado entre las partes establece una serie de responsabilidades legales que deben cumplirse de manera obligatoria, y que, en caso de incumplimiento, se puede recurrir a la v´ıa judicial para presentar una reclamaci´on. Seg´un ISO/IEC 19086-1 [40], entre los elementos m´as comunes que suelen definirse en los CAs podemos destacar: Acuerdos de nivel de servicio (SLAs): normalmente contienen una colecci´on de objetivos relativos al servicio en nube, que cubren aspectos del servicio. Pudiendo tratarse de la disponibilidad, fiabilidad, rendimiento, etc. Pol´ıtica de uso aceptable: se suelen definir los l´ımites del uso del servicio por parte del cliente. Pueden incluirse restricciones para que el cliente no tenga la posibilidad de realizar acciones maliciosas en los servicios. Pol´ıtica de seguridad: describe normalmente las responsabilidades del cliente y al proveedor en t´erminos de seguridad e indica qu´e certificaciones o normas de seguridad cumple el servicio en nube. Pol´ıtica de protecci´on de datos: suele tratar aspectos sobre el tratamiento de datos personales o datos sensibles por parte del servicio en la nube, e incluye las normas de calidad de las medidas espec´ıficas de protecci´on de datos y las certificaciones o normas de privacidad que se aplican al servicio. Pol´ıtica de continuidad del negocio: suele abordar las interrupciones del servicio en la nube y puede incluir medidas implementadas por el proveedor para prevenir la p´erdida de datos, como copias de seguridad y componentes redundantes. Pol´ıtica de actualizaci´on: abarca los cambios en las caracter´ısticas y funciones de los servicios cubiertos y los cambios relacionados con la interfaz de gesti´on. As´ı como las actualizaciones peri´odicas. Pol´ıtica de terminaci´on: suelen tratar las cuestiones que surgen cuando un cliente termina con el uso de servicios en la nube. En la pr´actica, observamos que desde un punto de vista l´ogico, este documento puede verse como una entidad ´unica con tres elementos claramente diferenciados (ver figura 3.1). Estos elementos son los t´erminos de uso, los planes de precios (pricing) y los SLAs. Los t´erminos de uso abarcan las responsabilidades generales de ambas partes sobre aspectos tales como el uso aceptable de los servicios, cambios en el acuerdo o los servicios, seguridad, protecci´on de datos y finalizaci´on del contrato, entre otros. El pricing describe diferentes configuraciones de uso con precios distintos [14]. Por otro lado, el SLA establece los compromisos que el proveedor asume para alcanzar los niveles objetivos fijados en uno o varios Indicadores de Nivel de Servicio (SLIs) y, opcionalmente, la compensaci´on (tambi´en conocida como cr´editos de servicio) que el cliente recibir´a en caso de no alcanzar el nivel en alguno de estos SLIs [26]. 16 Figura 3.1: Estructura l´ogica del CA [32] En general, cada proveedor gestiona sus aspectos legales de acuerdo a su propia consideraci´on. Algunos proveedores, como Rackspace 1, aplican una l´ogica como la que mencionamos anteriormente, mientras que otros, como GitHub 2, dividen los t´erminos de uso en varias pol´ıticas distintas (ver figura 3.2). En el caso de Rackspace, el CA consta de tres tipos de documentos, cada uno de ello con una funci´on espec´ıfica. El “Master Services Agreement” establece las condiciones legales generales aplicables a todos los servicios. El “Product Terms” define los t´erminos espec´ıficos aplicables a cada uno de los servicios disponibles. La “Service Order(s)” describe las funciones de los servicios, as´ı como las tarifas que pagar´a por ellos. Sin embargo, el CA de GitHub cuenta con varios documentos para los t´erminos espec´ıficos y adicionales de los servicios que proporciona. Agreement Set Master Services Ageement Product Terms Service Order(s) Product Terms Figura 3.2: Estructura del CA de Rackspace [34] y GitHub [16] La automatizaci´on en el an´alisis de los CAs puede facilitar a las partes a comprender las cl´ausulas que se describen en el mismo. 1https://www.rackspace.com/ 2https://github.com/ 17 Figura 3.4: Extracto del sitio web “Phoenix” problema de que los usuarios no lean las condiciones impuestas en los acuerdos y facilitar la comprensi´on de las mismas, identificando qu´e cl´ausulas son abusivas y cu´ales no. Para lograr esto, analizan las condiciones definidas en los acuerdos de servicios en l´ınea m´as utilizados, eval´uan cada una de sus proposiciones en diferentes niveles y valoran el grado de los t´erminos en base a la puntuaci´on de las cl´ausulas, como se muestra en la figura 3.4. El funcionamiento de la plataforma consiste en que las condiciones de servicio son revisadas por colaboradores, quienes discuten, comparan y asignan una puntuaci´on a cada una de ellas, utilizando categor´ıas como “Bueno”, “Malo”, “Bloqueador” o “Neutral”. Cuando un servicio tiene suficientes puntuaciones para evaluar la equidad de sus t´erminos, se asigna autom´aticamente una clasificaci´on ponderando las puntuaciones medias. Las clasificaciones de los servicios pueden ser: Grado A: las mejores condiciones del servicio, tratan con justicia, respetan los derechos y no abusan de los datos. Grado B: las condiciones son justas con el usuario, pero podr´ıan mejorarse. Grado C: las condiciones del servicio est´an bien, pero algunas cuestiones requieren ser consideradas. Grado D: las cl´ausulas son desiguales o algunas cuestiones importantes requieren de atenci´on. Grado E: las condiciones del servicio plantean problemas muy graves. Sin grado: se necesitan m´as datos sobre las cl´ausulas y m´as revisiones antes de poder asignar un grado. La plataforma act´ua como un repositorio de contratos que ofrece dos funciones principales para el usuario. En primer lugar, tienen la capacidad de agregar cl´ausulas para que sean evaluadas por colaboradores seg´un las categor´ıas previas establecidas. En segundo lugar, los usuarios pueden revisar las puntuaciones y las cl´ausulas abusivas 24 Figura 3.5: Extracto del sitio web “Term Scout” de los servicios que han sido analizados. Adem´as, se proporciona una extensi´on de navegador que permite visualizar las cl´ausulas y sus puntuaciones mientras eval´uas los t´erminos de uso del servicio en l´ınea. En esta l´ınea de trabajos, destaca la plataforma comercial Term Scout [30]. Su objetivo es facilitar la revisi´on de contratos, asegurando que las partes involucradas comprendan plenamente los t´erminos que est´an firmando. El sistema ofrece diversas funcionalidades, siendo la principal que act´ua como una base de datos que contiene contratos p´ublicos analizados a trav´es de un conjunto de preguntas relacionadas con las condiciones del acuerdo, por ejemplo, el an´alisis del CA de AWS se muestra en el figura 3.5. La herramienta ofrece distintos niveles de acceso a sus usuarios, cada uno con funcionalidades espec´ıficas. En la capa gratuita, los usuarios pueden explorar todos los contratos disponibles en el repositorio, interactuar ocasionalmente con un asistente virtual y analizar un n´umero limitado de acuerdos. Por otro lado, en la capa “Scout”, se ampl´ıa el n´umero de acuerdos que pueden ser a˜nadidos para su an´alisis y se brinda la posibilidad de comparar las caracter´ısticas de diferentes contratos. Adem´as, la plataforma cuenta con una capa configurable que permite a los usuarios crear su propio cat´alogo personalizado de preguntas y obtener una revisi´on m´as exhaustiva por parte de expertos legales. La plataforma cuenta con una pol´ıtica de certificaci´on de contratos21. Para obtener esta calificaci´on, se tienen en cuenta los 22 Principios de Contrataci´on de WorldCC22, los cuales son esenciales para garantizar contratos comerciales equilibrados. Estos principios son definidos por un tercero independiente y establecen los contenidos adecuados para la creaci´on de acuerdos justos. Cuentan con un extenso documento [10] donde explican cada uno de los principios y se detalla c´omo deber´ıan ser considerados en los t´erminos del acuerdo para que sea justo y equitativo para ambas partes involucradas. El documento se emplea para realizar una evaluaci´on mediante operaciones de an´alisis, con el fin de determinar si se est´an siguiendo las buenas pr´acticas derivadas de los Principios de Contrataci´on de WorldCC. 21https://blog.termscout.com/what-is-a-contract-certification 22https://www.worldcc.foundation/How-we-help/Contracting-Principles 25 Figura 3.6: Respuesta sobre el CA de Amazon Hasta el momento, esta aproximaci´on parece ser muy adecuada y alineada con nuestros objetivos futuros. Sin embargo, no hemos encontrado ning´un trabajo publicado que explique en detalle esta aproximaci´on o las t´ecnicas utilizadas para responder a las preguntas planteadas. La informaci´on disponible en su web solo menciona el uso de inteligencia artificial y abogados que revisan las condiciones de los acuerdos para proporcionar las respuestas al cat´alogo de 30 preguntas que disponen. Durante el uso de la versi´on gratuita de la herramienta, se han identificado diversas limitaciones que vale la pena mencionar. Una de ellas es que no todos los servicios ofrecen las mismas preguntas o evaluaciones. Por ejemplo, el acuerdo de Amazon se eval´ua en base a tres cat´alogos de preguntas, mientras que el de Microsoft solo cuenta con dos. Esto puede afectar la coherencia de los resultados y dificultar la comparativa entre diferentes proveedores. Por otra parte, es importante mencionar que aunque algunos servicios cuentan con una asistente virtual de inteligencia artificial para abordar aspectos legales del acuerdo, se han observado ocasiones en las que sus respuestas no son del todo precisas o correctas, lo que puede generar dudas sobre la fiabilidad de los an´alisis. Por ejemplo, al preguntar sobre el tiempo que se mantienen las condiciones de precio en el contrato de Amazon, la respuesta proporcionada por la asistente virtual no concuerda con los t´erminos establecidos en el acuerdo, como se muestra en la figura 3.6. Adem´as, se han experimentado dificultades al intentar incorporar un contrato a la plataforma de Term Scout, para que se realice el an´alisis del mismo en base al cat´alogo de preguntas propuesto. Aunque finalmente se logr´o que la herramienta revisara el SLA de Amazon EC2, los resultados obtenidos parecen no ser del todo consistentes, como en el caso de la indemnizaci´on al cliente por incumplimiento, donde se obtuvieron resultados contradictorios al acuerdo base, como se muestra en la figura 3.7. Finalmente, en relaci´on a los t´erminos de uso, mencionar un trabajo previo en el que se propone un cat´alogo de preguntas sobre las condiciones de los CAs. Este cat´alogo se basa en las preguntas formuladas por otros investigadores, as´ı como algunas 26 Figura 3.7: An´alisis del SLA de AWS EC2 que fueron propuestas por nosotros. Estas preguntas se clasificaron en tres escenarios de inter´es que facilitan la divisi´on de las operaciones desde el punto de vista del cliente, del proveedor y del contrato [32]. Siguiendo con los planes de precio, es fundamental destacar su importancia en el CA y los avances en su automatizaci´on. Las empresas que ofrecen productos o servicios emplean estrategias de planes de precios para generar ingresos. Estos planes suelen consistir en diferentes configuraciones de funcionalidades que se ofrecen a distintos precios [14]. Cada nivel de configuraci´on ofrecido est´a dise˜nado para satisfacer las necesidades de diferentes tipos de usuarios, desde aquellos con requerimientos m´as b´asicos hasta grandes empresas. Esta estrategia de negocio se emplea de manera general en el ´ambito industrial, incluyendo lo que se conoce como “API Economy”. Seg´un se˜nala Fresno et al. [11], en este escenario, las empresas proporcionan sus funcionalidades e informaci´on a trav´es de APIs p´ublicas, permitiendo a los desarrolladores integrarlas en sus propias aplicaciones. El pricing es una parte esencial del contrato que firman el proveedor y el cliente, porque la relaci´on legal entre las partes implica la prestaci´on de diferentes funcionalidades a un costo determinado. Esto significa que el proveedor est´a obligado a proporcionar las funcionalidades del servicio contratadas, y el cliente est´a obligado al pago de una cuota, es decir, se intercambian bienes econ´omicos por recursos funcionales. Como consecuencia, en caso de incumplimiento por alguna de las partes, el proveedor tendr´a el derecho a solicitar al cliente el valor econ´omico que le debe, y el cliente tendr´a el derecho a exigir la entrega del nivel de servicio contratado. El trabajo realizado por Fresno et al. [11] representa un avance notable en la automatizaci´on del an´alisis de los planes de precios. En su estudio, proponen un cat´alogo de operaciones de an´alisis enfocado en el cliente dentro del ´ambito del “API Economy”, lo que facilita la selecci´on de un plan adecuado de entre las opciones de precios de las APIs. El objetivo principal es permitir que el cliente tome decisiones informadas basadas en sus necesidades, considerando aspectos como las suscripciones, el presupuesto m´aximo, la capacidad requerida, el conjunto de funcionalidades deseado y el precio preferido. De esta manera, el cliente puede asegurarse de que los planes seleccionados se ajusten tanto a sus criterios espec´ıficos como a su presupuesto. 27 En t´erminos generales, la automatizaci´on de contratos no se restringe ´unicamente al an´alisis de los CAs en la nube, sino que su aplicaci´on ha sido m´as extendida en otros tipos de contratos. Cada contrato representa un documento legal que involucra obligaciones y derechos para todas las partes involucradas, lo que convierte a la automatizaci´on en una herramienta valiosa en diversos contextos contractuales. El trabajo realizado por Abhilasha Sancheti et al. [37] resalta la importancia de que las partes involucradas en un contrato comprendan claramente sus obligaciones, derechos, prohibiciones y permisos establecidos en el mismo. Mencionan que un sistema que pueda proporcionar un resumen de estos aspectos ser´ıa de gran utilidad tanto para las partes interesadas como para los profesionales del ´ambito jur´ıdico al revisar contratos. El motivo principal de su investigaci´on es la escasez de conjuntos de datos anotados para las modalidades de´onticas en el ´ambito legal. En respuesta a esto, presentan “LEXDEMOD”, un corpus de datos que contiene 7.092 frases extra´ıdas de 23 contratos de arrendamiento (empleo y alquiler) en ingl´es, todos ellos anotados con respecto a la modalidad de´ontica expresada por una de las partes contratantes o agentes. Para evaluar el conjunto de datos, se enfocan en dos tareas principales: clasificaci´on de la modalidad de´ontica espec´ıfica del agente con etiquetas m´ultiples, y detecci´on de la modalidad de´ontica espec´ıfica del agente y la acci´on que desencadena. Para abordar ambas tarea de clasificaci´on y detecci´on de la modalidad de´ontica, emplean el ajuste de varios modelos pre-entrenados a trav´es de Hugging Face, y destacan que obtuvieron los mejores resultados al entrenar el modelo “Roberta-L”. Adem´as, para medir la efectividad de su enfoque, comparan los resultados obtenidos con el an´alisis de contratos de otro tipo, encontrando un rendimiento inferior al de los contratos de arrendamiento. Tambi´en comparan sus resultados de detecci´on de cl´ausulas peligrosas con los de un trabajo anterior, y obtienen mejores resultados, logrando detectar m´as oraciones problem´aticas. La aproximaci´on de este trabajo es interesante y prometedora, aline´andose con nuestros objetivos futuros. Sin embargo, es esencial resaltar las limitaciones que los propios autores han se˜nalado en su art´ıculo. Una de las principales es que los resultados obtenidos no alcanzan el nivel ´optimo esperado debido a la restricci´on del conjunto de datos a contratos de arrendamiento exclusivamente. Adem´as, otra dificultad deriva del enfoque de extracci´on de proposiciones, ya que se limita ´unicamente a aquellas que mencionan expl´ıcitamente al agente. Un problema de gran relevancia que se destaca en este trabajo es la falta de disponibilidad del c´odigo fuente y la inaccesibilidad del conjunto de datos utilizado en la investigaci´on. Aunque se menciona la existencia de un repositorio en GitHub, lamentablemente este no est´a disponible p´ublicamente, lo que dificulta la posibilidad de reproducir y verificar los resultados. Adem´as, en el art´ıculo no se menciona que el modelo haya sido compartido en Hugging Face u otros repositorios tras su entrenamiento, lo que podr´ıa favorecer su uso y reutilizaci´on. En esta misma l´ınea de investigaci´on, destaca el trabajo de Ruka Funaki et al. [13], quienes han desarrollado un corpus de datos con la informaci´on contenida en los contratos legales. En su estudio, se enfocan en etiquetar 46 contratos legales en 28 ingl´es y 25 contratos legales en japon´es, identificando tanto las partes involucradas que firman el acuerdo, as´ı como los derechos y obligaciones espec´ıficos de cada una de ellas. Adem´as, identifican las condiciones necesarias para que estos derechos y obligaciones surtan efecto, as´ı como las excepciones que podr´ıan aplicarse a dichas condiciones. Para evaluar la efectividad del corpus, los investigadores llevan a cabo un experimento preliminar en el cual entrenan un modelo BiLSTM-CRF, que combina una red neuronal bidireccional LSTM (BiLSTM) con un modelo de Campo Aleatorio Condicional (CRF) [19]. La red BiLSTM es capaz de capturar el contexto tanto pasado como futuro de cada palabra en el contrato, lo que permite reconocer secuencias de palabras que corresponden a derechos y obligaciones. Asimismo, dise˜nan otro m´odulo basado en el aprendizaje autom´atico con el prop´osito de vincular cada derecho u obligaci´on con la parte involucrada correspondiente en el contrato. De manera similar al art´ıculo anterior, la falta de acceso al conjunto de datos sigue siendo un obst´aculo en este caso. Lamentablemente, no se ha encontrado ninguna referencia al corpus etiquetado utilizado en la investigaci´on. Esta carencia de informaci´on sobre el conjunto de datos etiquetado es una limitaci´on significativa, ya que nos impide utilizarlo como base para nuestro trabajo. 3.3.1. An´alisis autom´atico de SLAs Los SLAs han sido ampliamente estudiados en el ´ambito acad´emico, desde la definici´on de modelos para especificar, gestionar y compartir descripciones de los SLAs de la web hasta la automatizaci´on para extraer informaci´on relevante y realizar el an´alisis de los mismos a trav´es de operaciones de an´alisis. En esta secci´on, exploraremos en qu´e consisten exactamente los SLAs y las diversas aproximaciones conocidas en relaci´on con su automatizaci´on. Los SLAs son com´unmente empleados por las empresas, ya sea interna o externamente, independientemente del tipo de productos o servicios que provean. Un SLA puede entenderse como un documento contractual entre un cliente y un proveedor en el que se establecen las expectativas de rendimiento y las consecuencias en caso de que el servicio no cumpla con esas expectativas [3]. Al igual que ocurre con el CA, es importante tener en cuenta que llamar a estos contratos “acuerdos” puede considerarse un eufemismo, ya que los proveedores suelen ofrecerlos en un formato est´andar, sin fase de negociaci´on con el cliente en la que se discutan y acuerden diferentes cl´ausulas, observ´andose la superioridad del proveedor con respecto al cliente. Es importante destacar que los SLAs no cuentan con una estructura normativa est´andar ampliamente aceptada por los proveedores de servicios. Aunque existen organizaciones como como Organizaci´on Internacional de Normalizaci´on (ISO) y la Comisi´on Electrot´ecnica Internacional (IEC) que han trabajado en el estabilizaci´on de un conjunto de componentes b´asicos que puedan emplearse a modo de gu´ıa para construir, modificar o entender los acuerdos de la nube [40]. Del mismo modo, el Instituto Nacional de Est´andares y Tecnolog´ıa (NIST) considera los acuerdos como una parte esencial en la gesti´on de servicios, ya que un acuerdo correctamente definido permite reducir los conflictos de intereses entre las partes. Por ello, el NIST define una serie de 29 elementos esenciales que todo acuerdo deber´ıa contener, resaltando la importancia de que las partes sean conscientes de sus funciones y responsabilidades [27]. Por otro lado, destaca el proyecto financiado por la Comisi´on Europea, Cloud Model SLA, que define un modelo de SLA como gu´ıa para facilitar la comprensi´on de estos acuerdos [3]. A pesar de esto, cada proveedor aplica las normativas que mejor se adaptan a sus necesidades, lo que dificulta la automatizaci´on de cualquier proceso relacionado con ellos. No obstante, la mayor´ıa de los acuerdos suelen incluir elementos esenciales que permiten definir las obligaciones y derechos con mayor inter´es de los SLAs, los cuales ser´an mencionados a continuaci´on. Adem´as, dependiendo del tipo de servicio ofrecido, es com´un encontrar similitudes en la informaci´on proporcionada. En referencia a la informaci´on incluida en el SLA, las expectativas de rendimiento suelen expresarse mediante dos elementos claves. El primero de ellos son los Indicadores de Nivel de Servicio (SLIs), que son medidas cuantitativas definidas sobre propiedades del servicio prestado [17]. Por ejemplo, en el caso de un servicio computacional, un indicador com´un para medir el rendimiento es la disponibilidad. Sin embargo, en un servicio no computacional, un indicador podr´ıa ser el tiempo de resoluci´on de un incidente. El segundo elemento son los Objetivos de Nivel de Servicio (SLOs), que se definen como valores objetivos o rangos de valores para una propiedad del servicio que se mide mediante un SLI [17]. Siguiendo con el ejemplo anterior, un SLO para un servicio computacional podr´ıa ser que la disponibilidad esperada debe ser igual o superior al 99.5 %, mientras que para un servicio no computacional, podr´ıa ser que el tiempo de resoluci´on de un incidente se espera que sea inferior a 3 horas. Por otro lado, las consecuencias por el incumplimiento de los objetivos suelen reflejarse en compensaciones econ´omicas para el cliente, tambi´en conocidas como Cr´editos de Servicio. Por ejemplo, si la disponibilidad es inferior al 99.5 %, el proveedor podr´ıa tener que reembolsar el 10 % de la cuota de suscripci´on al cliente. Estos tres t´erminos suelen ser abordados en la mayor´ıa de los SLAs. Las m´etricas (SLIs) y los objetivos (SLOs) son considerados como requisitos obligatorios, ya que son fundamentales para que el acuerdo tenga un significado claro. Estos componentes son clave para medir la calidad del servicio proporcionado, ya que una m´etrica implica una f´ormula que permite realizar mediciones, mientras que un objetivo establece la meta que el proveedor se propone alcanzar. Esto indica una responsabilidad del proveedor de cumplir con el objetivo esperado. Por otro lado, las compensaciones son opcionales, pero se recomiendan para que el acuerdo tenga un impacto pr´actico. Esto significa que son necesarias para motivar al proveedor a esforzarse en cumplir con los objetivos establecidos y proporcionar seguridad al cliente, ya que esto le otorga al cliente el derecho de solicitar una reclamaci´on de cr´editos en caso de incumplimiento. De manera directa, los SLAs establecen derechos y responsabilidades tanto para el proveedor como para el cliente [3]. Esto implica que ambas partes tendr´an que realizar una serie de actividades para cumplir con los t´erminos y condiciones definidas en el acuerdo. Por otro lado, los derechos otorgan a cada una de las partes la capacidad de realizar ciertas acciones dentro de los l´ımites establecidos. Adem´as, tambi´en es com´un que se detallen derechos negados, es decir, prohibiciones que restringen a una de las 30 partes de realizar determinadas acciones. Por ´ultimo, otro aspecto a tener en cuenta es que los acuerdos est´an sujetos a cambios a lo largo del tiempo. Es inevitable que evolucionen debido a que los servicios se encuentran en constante desarrollo, ya sea a˜nadiendo nuevas funcionalidades, ampliando las capacidades del sistema, mejorando los mecanismos de monitorizaci´on, etc. esto implica que existan cambios en los t´erminos y condiciones que se definen en el acuerdo [40]. En el campo del an´alisis autom´atico de SLAs, uno de los trabajos m´as novedosos es el realizado por Natolana et al. [15]. En este trabajo, se presenta un marco integral para la extracci´on de conocimiento del SLA combinando t´ecnicas de miner´ıa de textos, web sem´antica y NLP. En dicho trabajo, se describe un enfoque que utiliza patrones y t´ecnicas tradicionales de NLP para extraer informaci´on relevante contenida en los SLAs. Esta informaci´on se representa utilizando un grafo de conocimiento, con el fin de estructurarla de manera sem´antica. El objetivo final es proporcionar al cliente las herramientas necesarias para tomar decisiones fundamentadas al elegir proveedores que ofrecen un servicio digital a trav´es de la nube. No obstante, una limitaci´on importante de esta idea se analiza en uno de nuestros trabajos previos titulado ”Limitations of current techniques to detect Obligations and Rights in SLA”[33]. Esta limitaci´on radica en la tendencia al uso de patrones para identificar los contenidos del acuerdo. En concreto, una de las tareas que realizan es la extracci´on de responsabilidades. Como soluci´on, definen una serie de premisas que deben cumplir las cl´ausulas para que estas sean identificadas como una acci´on obligatoria o un derecho exigible. Las reglas que se establecen son: Regla 1: las declaraciones que contengan las palabras en ingl´es “must”, “should” y “will” implican una obligaci´on directa para el actor que se indique en la cl´ausula. Regla 2: las declaraciones son detectadas si cumplen con la siguiente estructura de oraci´on en ingl´es: <noun/pronoun><modal verb><verb> A pesar de que muchas cl´ausulas en los acuerdos se ajustan a las directrices propuestas por Natolana et al., existen excepciones que no siguen estas reglas. Por ejemplo, algunas proposiciones pueden no requerir un verbo modal, pero indicar una obligaci´on o un derecho. Cuando una oraci´on no cumple con la regla 2, ese enunciado se omite. Tambi´en hay ocasiones en las que cl´ausulas que incluyen el verbo modal “will” transmiten un derecho. Est´a limitaci´on da lugar a clasificaciones err´oneas. Otra de las tareas propuestas por Natolana es identificar el actor que debe o tiene la posibilidad de realizar la acci´on que se define en la cl´ausula. La soluci´on que se aplica es la evaluaci´on de las categor´ıas gramaticales de las palabras de la oraci´on. Para etiquetar la categor´ıa gramatical de cada palabra en la frase, se utiliza la t´ecnica de etiquetado de partes de la oraci´on (part-of-speech tagging) [39]. El modelo que proponen es un bucle que comprueba dos posibles condiciones para cada palabra de la frase: Si la palabra anterior es el sujeto nominal y la palabra actual es un verbo auxiliar en ingl´es, entonces el actor es el anterior. Un ejemplo ser´ıa: “At our discretion, 31 we may issue the Service Credit to the credit card...”. En el otro caso, si la palabra precedente es el verbo principal y la palabra actual es el sustantivo que recibe la acci´on, entonces el actor es la palabra actual. Un ejemplo ser´ıa: “Your failure to provide the request will disqualify you from receiving a Service Credit”. El principal problema de este patr´on es detectar frases en ingl´es que est´an escritas en voz pasiva, como por ejemplo: “maximum number of Financial Credits to be issued by Google to the customer...”. Un enfoque adicional para extraer informaci´on de los SLAs es presentado por Lucia De Marco et al. [5]. Su objetivo principal es lograr la extracci´on autom´atica de los SLOs. Para alcanzar este objetivo, siguen un procedimiento que implica clasificar las cl´ausulas en tres categor´ıas: Definici´on, Valor y No definici´on. A continuaci´on, buscan obtener m´as detalles de las oraciones que indican “Definici´on”, como la f´ormula y el periodo correspondiente. Adem´as, extraen informaci´on de las oraciones que indican “Valor”, incluyendo el valor num´erico del par´ametro y su unidad de medida. El enfoque se apoya en el software General Architecture for Text Engineering (GATE), que ofrece herramientas para la aplicaci´on de tareas de NLP. GATE cuenta con diversos complementos que facilitan el preprocesado del texto, la implementaci´on de algoritmos de aprendizaje autom´atico y la creaci´on de reglas para etiquetar documentos, entre otras funcionalidades. Para la clasificaci´on de las cl´ausulas preprocesadas, se aplican cinco algoritmos: SVM, Algoritmo de Perceptr´on con M´argenes Desiguales (PAUM), Naive Bayes, Algoritmo del Vecino m´as Cercano (KNN) y ´ Arbol de Decisi´on C4.5. Los resultados se contrastan con el conjunto de datos clasificados manualmente, utilizando medidas de bondad como precisi´on, recall y f-measure. Se observa que el modelo de clasificaci´on SVM obtiene los mejores resultados. Para identificar f´ormulas, se utiliza el lenguaje Java Annotation Patterns Engine (JAPE) para construir reglas y etiquetar las oraciones. La precisi´on se eval´ua mediante f´ormulas de distancia, incluyendo la distancia Levenshtein, la similitud Jaccard y la similitud coseno. Estas m´etricas permiten calcular el error al comparar la salida obtenida con la esperada. 3.3.2. An´alisis autom´atico con l´ogica de´ontica Seg´un Risto Hilpinen [18], la l´ogica de´ontica es un ´area de la l´ogica que investiga los conceptos normativos, los sistemas de normas y el razonamiento normativo. Desde los inicios del siglo veinte se realizaron varios estudios que hacen menci´on a la deontolog´ıa y la l´ogica del deber. Aun as´ı, el primer intento de sistematizaci´on lo realiza Leibniz que denomino “modalidades jur´ıdicas”, Juris modalia, a las categor´ıas de´onticas de lo obligatorio, lo permitido y lo prohibido, y observ´o que los principios b´asicos de la l´ogica modal son v´alidos para las modalidades jur´ıdicas. Finalmente, el desarrollo de la l´ogica de´ontica nace con la publicaci´on del trabajo de Von Wright “Deontic Logic” que se basa en el estudio de las analog´ıas entre las nociones de´onticas y modales. Es 32 decir, las nociones de permiso, prohibici´on y obligaci´on se relacionaban entre s´ı igual que los cuantificadores y las modalidades b´asicas [18,45]. Tras las primeras definiciones de la l´ogica de´ontica, se han desarrollado diferentes enfoques y avances sobre como simbolizar en una f´ormula la acci´on que expresa la norma que se eval´ua. Esto se debe a que la normatividad en general presenta un reto en s´ı misma, y llegar hasta los cuantificadores que permitan formalizar una proposici´on con todos sus significados introduce una considerable complejidad l´ogica. Actualmente siguen existiendo algunos problemas o retos pendientes en los criterios definidos [25]. Por este motivo, en este trabajo, tomaremos como base parte de los conceptos tratados en los art´ıculos “Deontic Logic: A Personal View” de Georg Henrik Von Wright [45] y “Modeling Behavioral Deontic Constraints Using UML and OCL” de Antonio Vallecillo y Martin Gogolla [43]. Este ´ultimo, presenta un caso de estudio en el que se aplican estas ideas l´ogicas para la especificaci´on de restricciones de un sistema, en base al comportamiento que debe o puede hacer el usuario. El primer intento para proporcionar los fundamentos sobre los s´ımbolos formales en la l´ogica de´ontica se recoge en el libro “Norm and Action” de Von Wright. En el que las variables p, q, etc. se entienden como representaciones esquem´aticas de la acci´on humana y est´as acciones pueden contar con un “estado de´ontico” diferente como obligatorio, permitido o prohibido. Las normas pueden expresarse con los operadores modales Op y Pp, esto se puede leer como “Es obligatorio que p” y “Est´a permitido que p”. Por ejemplo, imaginemos la restricci´on “Los alumnos pueden ver las notas s´olo de sus informes”, la proposici´on l´ogica puede definirse como ϕ= ver las notas s´olo de sus informes, y el estado es permitido. Esto queda representado como P(ϕ). Los comportamientos que se definen en los sistemas deben ser ejecutado por un usuario conocido, en el caso anterior, el estudiante (an´alogo a los contratos). Este se convierte en el responsable de llevar a cabo las acciones apropiadas para cumplir las obligaciones correspondientes. Del mismo modo, el agente puede tener asociados permisos, acciones que puede realizar, o prohibiciones, acciones que no puede llevar a cabo. Como se indica en [43], esto permite razonar sobre las responsabilidades de los objetos (sujeto) y, lo que es m´as importante, saber a qui´en responsabilizar cuando se producen problemas o violaciones del contrato. Otra noci´on de inter´es que se debe aplicar en este trabajo es la noci´on de norma de negaci´on. A menudo, se emplea el estado “No est´a permitido” para referirse a “Est´a prohibido” y viceversa, esto quiere decir que las prohibiciones no son m´as que la negaci´on de un permiso. Por ejemplo, una prohibici´on podr´ıa ser “Los estudiantes no pueden ver las notas de los informes de sus compa˜neros”. De manera simb´olica las reglas de negaci´on modal se pueden representar como ¬O(ϕ)≡P(¬ϕ) y ¬P(ϕ)≡O(¬ϕ). Esto quiere decir, que no obligar a realizar una acci´on es equivalente a tener permiso de realizar lo contrario y, de la misma forma, prohibir un hecho es equivalente a obligar a que no se lleve a cabo. Finalmente, se debe mencionar que el t´ermino de´ontico significa lo relativo a la obligaci´on moral. Esto quiere decir, que las reglas de´onticas podr´ıan infringirse, aunque no debieran. Normalmente, el incumplimiento de una regla suele tener un impacto negativo en el agente responsable. 33 Caracter´ısticas all-roberta- large-v123 paraphrasempnet-base-v224 paraphrase- MiniLM-L3-v225 Rendimiento medio 61.64 57.70 50.74 Velocidad (oraciones/segundo) 800 2800 19000 Tama˜no 1360 MB 420 MB 61 MB Codificadores 24 12 3 Cabeceras de atenci´on 16 12 12 Tabla 3.1: Caracter´ısticas de los modelos 3.4.3. Prompt Engineering El potencial de los LLMs en el campo de la ingenier´ıa inform´atica y el desarrollo de aplicaciones es enorme. Act´uan de manera similar a otros sistemas a los que se les puede realizar llamadas a la API, pero en este caso se obtienen respuestas contextuales e inteligentes basadas en la entrada. Como se mencion´o previamente, los modelos preentrenados con millones de datos de texto pueden ser empleados para abordar tareas de manera predeterminada o a trav´es de un entrenamiento adicional utilizando conjuntos de datos espec´ıficos. Esta decisi´on puede depender de diferentes factores como la arquitectura del modelo, la cantidad de datos utilizados en su entrenamiento inicial, la tarea espec´ıfica que se desea realizar (ya sea relacionada con un problema de negocio o de naturaleza general), el conjunto de datos disponible para ajustar el modelo y resolver la tarea deseada, entre otros. Una de las formas m´as sencillas de utilizar estos modelos en sistemas reales es hacerles preguntas sobre el problema espec´ıfico que se desea resolver. Por esta raz´on, como indica Open AI [1], es importante proporcionar instrucciones claras al modelo. Estamos solicitando a una red neuronal inteligente que realice una tarea que posiblemente no conoce, por lo tanto, es necesario ser lo m´as expl´ıcitos posible y proporcionar un contexto completo. La aplicaci´on de esta t´ecnica en el presente trabajo tiene como objetivo detectar el sujeto que debe realizar la acci´on en las oraciones extra´ıdas del texto. Esto se debe a que la tarea es de naturaleza gen´erica y no depende directamente del ´ambito de estudio. Por lo tanto, ser´ıa costoso entrenar un modelo pre-entrenado, principalmente debido a la falta de datos disponibles. En base a lo anterior, existen algunos principios y t´acticas para generar instrucciones de entrada. Tomaremos como referencia el curso “ChatGPT Prompt Engineering for Developers” impartido por Isa Fulford y Andrew Ng [12]. En primer lugar, debemos tener claro que el proceso de desarrollo de las prompts es iterativo y, probablemente, imperfecto. Los pasos recomendados por los instructores se indican en la figura 3.9. El procedimiento consiste en ser claro y espec´ıfico en la instrucci´on, analizar por qu´e 40 los resultados no dan la salida esperada, redefinir la idea y generar otra instrucci´on de entrada. Figura 3.9: Ciclo iterativo sobre el desarrollo de prompt Los principios que se determinan para generar una buena entrada en el modelo y que se obtengan los mejores resultados son los siguientes: 1. Escribir claro y con instrucciones espec´ıficas. T´actica 1: usar delimitadores como comillas, comillas simples, guiones, etc. T´actica 2: especificar una estructura como salida. Es decir, obligar al modelo a devolver un HTML o JSON por ejemplo. T´actica 3: exigir al modelo realizar una serie de pasos para completar la tarea. T´actica 4: realizar un “entrenamiento” con pocos ejemplos, proporcionando al modelo escenarios satisfactorios para que complete la tarea con un mayor rendimiento. 2. Dar al modelo suficiente tiempo para pensar. T´actica 1: especificar los pasos para completar una tarea y determinar el formato de salida esperada fomenta a que el modelo realice un mayor razonamiento sobre la respuesta. T´actica 2: cuestionar al modelo que realice primero el trabajo por si mismo y despu´es eval´ue la soluci´on que se le proporciona. Es decir, si se desea comprobar que un c´alculo matem´atico es correcto, se le debe indicar al modelo que resuelva el problema por si mismo y despu´es compare ambas soluciones. A pesar de que los modelos han sido expuestos a grandes cantidades de datos durante el proceso de entrenamiento, no memorizan a la perfecci´on. Debemos considerar que los modelos presentan limitaciones y que en ocasiones esta t´ecnica no es adecuada para resolver todas las tareas de extracci´on de informaci´on del texto. Uno de los problemas m´as reconocidos son las Hallucinations, los modelos pueden realizar afirmaciones que parecen aceptables pero que no son ciertas. Otros inconve- 41 nientes de los modelos son su acotada longitud de la entrada y las limitaciones de datos de entrada que es capaz de tener en cuenta. 3.5. Resumen y conclusiones En este cap´ıtulo, se han revisado los trabajos anteriores relacionados con el an´alisis autom´atico de contratos. El objetivo ha sido presentar las alternativas de soluci´on aplicadas en el contexto del tema, se˜nalando las limitaciones encontradas en cada uno de ellas. Adem´as, se han explorado los conceptos de dos ´areas que podr´ıan ser el medio para resolver los problemas planteados, la l´ogica de´ontica y el NLP. Se ha observado que cada una de las herramientas existentes se enfoca en resolver un problema espec´ıfico dentro del ´ambito de los contratos, utilizando diversas t´ecnicas de NLP. A modo de resumen sobre los enfoques estudiados, se destacan las caracter´ısticas resumidas en la tabla 3.2. Aproximaci´on Contexto Tarea Soluci´on Claudette [24] T´erminos de uso Detecci´on clausulas abusivas SVM [41] Phoenix [20] T´erminos de uso Detecci´on clausulas abusivas An´alisis Manual Term Scout [30] T´erminos de uso Operaciones an´alisis IA y expertos legales Fresno et al. [11] Pricing Operaciones an´alisis Resolutor CSPO 26 Abhilasha Sancheti et al. [37] Contratos Corpus y modelo para detectar obligaciones y derechos Transformers Ruka Funaki et al. [13] Contratos Corpus y modelo para detectar obligaciones y derechos BiLSTM- CRF [19] Natolana et al. [15] SLA Detecci´on obligaciones y derechos Patrones Lucia De Marco et al. [5] SLA Detecci´on SLOs GATE [4] Tabla 3.2: Caracter´ısticas de las herramientas estudiadas 26Problema de Satisfacci´on de Restricciones y Optimizaci´on 42 4. Descripci´on de la propuesta 4.1. Introducci´on En este cap´ıtulo, se presenta y describe nuestra propuesta de dise˜no e implementaci´on de un sistema para automatizar el an´alisis de los CAs. Nuestro objetivo es desarrollar un sistema que pueda comprender el lenguaje natural de los acuerdos y realizar razonamientos sobre ellos, en l´ınea con el inter´es actual en este tipo de sistemas. En adelante nos referiremos a esta propuesta como iCan (i-Customer Agreement aNalyzer), pues tiene vocaci´on de razonar sobre cualquier aspecto de los CAs. La primera aproximaci´on del sistema se centra en la capacidad de extraer de manera autom´atica las obligaciones, derechos y responsables de cada acci´on que se menciona en el acuerdo. Esto permite realizar razonamientos basados en la informaci´on extra´ıda del CA. En las siguientes secciones se abordar´a la soluci´on propuesta para cada uno de los problemas planteados, se describir´a la arquitectura que sigue el sistema, se presentar´an los detalles de la prueba de concepto realizada, as´ı como los desaf´ıos futuros y las conclusiones obtenidas. 4.2. Propuesta de soluci´on En base al problema de clasificaci´on de cl´ausulas definido en la secci´on 1.4, es evidente que realizar autom´aticamente esta tarea presenta una dificultad clara, los CAs se definen en lenguaje natural, por lo que no son comprensibles por las m´aquinas. Por lo tanto, identificar informaci´on espec´ıfica en el texto a menudo resulta inefectivo si no se aplican t´ecnicas de NLP capaces de comprender el significado de las entradas proporcionadas. Se han explorado varias soluciones existentes para el problema de clasificaci´on de cl´ausulas (ver secci´on 3.2). Sin embargo, algunas de estas soluciones presentan limitaciones en la comprensi´on del texto, lo que puede llevar a la detecci´on err´onea de oraciones. Adem´as, otras soluciones carecen de un sistema inform´atico que facilite a los usuarios el an´alisis de acuerdos desde una interfaz gr´afica. Es por ello, que como alternativa para abordar el subproblema de categorizar las obligaciones y derechos, se propone utilizar un modelo preentrenado basado en transformers. Se busca optimizar este modelo mediante el uso de un conjunto de datos espec´ıfico que permita identificar cl´ausulas de los CAs seg´un el estado que expresan, ya sea una obligaci´on o un derecho. La clasificaci´on de proposiciones del CA implica directamente dos tareas, primero obtener el modelo entrenado con el conjunto de datos de obligaciones y derechos que permitan resolver la tarea espec´ıfica que se propone y posteriormente el sistema a desarrollar debe tener la capacidad de extraer las oraciones de un nuevo acuerdo dado y ejecutar el modelo clasificador para extraer aquellas que indiquen obligaci´on o derecho. 43 En cuanto a la identificaci´on del actor responsable de realizar la acci´on. Se propone utilizar el modelo generativo GPT-3.5 turbo desarrollado por Open AI [29], que es un modelo potente capaz de generar una respuesta basada en una entrada cuidadosamente elaborada. La entrada al modelo se basa en la informaci´on extra´ıda anteriormente, es decir, las cl´ausulas que indican obligaci´on y derecho en el CA. Adem´as, el prompt incluye un conjunto de ejemplos de oraciones clasificadas junto con el actor que debe realizar la acci´on, a modo de datos de entrenamiento. Con esta informaci´on el modelo debe ser capaz de extraer la mayor´ıa de los sujetos correctamente. De hecho, seg´un Open AI [28] estos modelos son capaces de realizar funciones de an´alisis de texto, y han demostrado ofrecer resultados significativos y eficientes en tareas de an´alisis de oraciones, por ejemplo, b´usqueda de informaci´on, detecci´on de anomal´ıas y clasificaci´on. En relaci´on al segundo problema identificado en la secci´on 1.4, referido al an´alisis del acuerdo, es decir, a razonar sobre la informaci´on que este contiene, se propone abordar preguntas espec´ıficas relacionadas con tres caracter´ısticas claves, que pueden ser de inter´es tanto para el cliente como para el proveedor: los beneficios, la falta de responsabilidad y los riesgos. Se elige esta aproximaci´on inspir´andonos en la soluci´on propuesta por Term Scout para el an´alisis de los t´erminos de uso, secci´on 3.3. Como propuesta inicial, se plantea la creaci´on de un cat´alogo de preguntas a las que se pueda dar respuesta en funci´on de las obligaciones y derechos identificados en el acuerdo. Esto permitir´a a las partes evaluar el contrato desde diferentes perspectivas. Por ejemplo, el cliente podr´a determinar c´omo afecta la firma del acuerdo a su negocio antes de la contrataci´on del mismo. El objetivo final es automatizar este proceso y proporcionar respuestas a todas estas preguntas sobre cualquier acuerdo que se desee analizar. A modo de conclusi´on, la presente propuesta de soluci´on integra tres fases fundamentales con el objetivo de abordar de manera efectiva los dos problemas planteados. Este proceso es el que se muestra en la Figura 4.1. La primera fase se enfoca en la extracci´on de cl´ausulas de modalidad de´ontica. La segunda fase se centra en obtener del actor que debe realizar la acci´on. Por ´ultimo, la tercera fase implica la ejecuci´on de m´etricas espec´ıficas para razonar sobre la informaci´on extra´ıda. Dando respuestas parciales a una serie de preguntas importantes, tales como: ¿Cu´ales son los riesgos a los que se enfrenta el cliente al firmar este acuerdo? ¿Existen lagunas de responsabilidad en el CA? ¿Qui´en se beneficia m´as con este CA? Figura 4.1: Etapas del sistema iCan 44 4.2.1. Identificaci´on de obligaciones y derechos Con el prop´osito de automatizar la detecci´on de oraciones que expresan obligaci´on y derecho, se requiere un modelo con la capacidad de abordar esta tarea de manera precisa. Puesto que no se conoce una soluci´on espec´ıfica dise˜nada para la clasificaci´on requerida en el contexto de los CAs, se busca adaptar los modelos preentrenados con grandes vol´umenes de texto detallados en la tabla 3.1 y comparar los resultados que obtienen frente a nuestro conjunto de datos. Para lograr este objetivo, resulta esencial contar con un corpus claro y completo que englobe una amplia variedad de oraciones. Esto implica que las cl´ausulas deben ser lo m´as diversas posible, para permitir al modelo generalizar y comprender las distintas categor´ıas existentes. La recopilaci´on de las cl´ausulas debe realizarse de manera manual, debido a la falta de un conjunto de datos espec´ıfico adecuado para este contexto. Este proceso toma como fundamentos los conceptos normativos definidos en la secci´on que trata la l´ogica de´ontica aplicada a los acuerdos. En ella, se determinan las categor´ıas que ser´an empleadas en la clasificaci´on y se definen algunos conceptos que facilitan la identificaci´on de las oraciones que indican acciones obligatorias o derechos (secci´on 3.3.2). Adem´as, se emplean los acuerdos enlazados en la documentaci´on sobre los diversos proveedores para obtener cl´ausulas en base a la tem´atica, detallada en la secci´on 3.2.1. Finalmente, se aplica el conocimiento sobre los CAs y su automatizaci´on (secciones 3.2 y3.3) para generar una gu´ıa sobre la clasificaci´on de oraciones. Dada la complejidad y las restricciones temporales para obtener un conjunto de datos apropiado para el an´alisis de obligaciones y derechos en CAs, en esta primera versi´on se proporciona un cat´alogo limitado de cl´ausulas eficientes destinadas a los SLAs. El proceso que se sigue, desde la adquisici´on de los documentos en la nube hasta la generaci´on de los conjuntos de datos, est´a representado en el diagrama de la figura 4.2. Los SLAs se han obtenido de los sitios web de los proveedores de servicios en la nube (3.2.1). En concreto, se han seleccionado 52 documentos de un total de 18 proveedores, en algunos de ellos ´unicamente se describen las expectativas de rendimiento de un servicio, mientras que otros abarcan todos los servicios que el proveedor ofrece. Figura 4.2: Proceso para la obtenci´on de los datasets 45 Para abordar la clasificaci´on manual de obligaciones y derechos es necesario contar con una serie de instrucciones que faciliten la identificaci´on de cada proposici´on en los acuerdos. La gu´ıa generada se adjunta como anexo A.1. Para su creaci´on, se han considerado los conceptos mencionados en investigaciones previas [15,37], as´ı como los conocimientos adquiridos acerca de los acuerdos como se ha mencionado anteriormente. En las instrucciones se detallan las etiquetas en las que se clasifican las oraciones. Estas categor´ıas son las siguientes: Obligaci´on (Obligation): oraciones que establecen un v´ınculo que obliga a llevar a cabo o abstenerse de realizar una acci´on [7]. Derecho (Right): proposiciones que conceden la posibilidad moral o legal de hacer o exigir algo [8]. Ninguna (Neither): frases que no indican obligaci´on o derecho, son meramente informativas o condicionales. Tambi´en se mencionan situaciones generales que pueden concluir en una obligaci´on o derecho para alguna de las partes, junto con ejemplos de oraciones que se han agrupado en esa categor´ıa. Esta aproximaci´on es posible porque las obligaciones y derechos del proveedor y el cliente suelen diferir, ya que una de las partes contrata el servicio mientras que la otra lo proporciona. Por ejemplo, una obligaci´on t´ıpica del cliente es la reclamaci´on de las compensaciones cuando el proveedor incumple con sus objetivos, como por ejemplo “In order to receive a credit under this SLA, Customer must first open a trouble ticket to report and request resolution to the incident”. Sin embargo, una obligaci´on del proveedor suele ser la prestaci´on de los servicios a un nivel de rendimiento esperado, como “AWS will use commercially reasonable efforts to make Alexa for Business available (. . . ) of at least 99.9 %”. Por otro lado, uno de los derechos m´as representativos desde el punto de vista del cliente es tener la posibilidad de recibir compensaciones econ´omicas si el proveedor no cumple los SLOs o los t´erminos acordados en el contrato, tal como se refleja en la siguiente oraci´on “You will be eligible to receive a Service Credit as described below”. En cambio, el proveedor generalmente cuenta con el permiso para realizar modificaciones en el acuerdo o en los servicios que ofrece, entre otras “Verizon reserves the right to perform maintenance outside of Scheduled Maintenance during an emergency situation”. Con el fin de facilitar el an´alisis, etiquetado y revisi´on de cada uno de los documentos se emplea MAXQDA, un software que permite visualizar, organizar y exportar la clasificaci´on de las oraciones. En la figura 4.3 se presenta la interfaz de esta herramienta y algunas de las posibilidades que ofrece, como la capacidad de establecer c´odigos y asignarlos a cada una de las frases del acuerdo. La limpieza de los datos es necesaria debido a que, en la mayor´ıa de los casos, los acuerdos incluyen una cantidad significativa de oraciones que son principalmente informativas o condicionales, observar gr´afico 4.4. Por lo tanto, para que el modelo aprenda de manera equilibrada y detecte con precisi´on las cl´ausulas en todas las categor´ıas, se opta por utilizar una submuestra del conjunto total de frases del acuerdo. En otras palabras, se iguala la cantidad de entradas por categor´ıa en los conjuntos de datos. Esto implica la eliminaci´on de oraciones repetidas o similares. 46 Figura 4.3: Etiquetado de cl´ausulas con MAXQDA Durante el proceso de limpieza de los datos, se identific´o un problema relacionado con la similitud en la redacci´on de los acuerdos. Se observ´o que algunas de las cl´ausulas definidas en los SLAs eran pr´acticamente id´enticas. Emplear estos datos para la adaptaci´on del modelo no es la opci´on m´as ´optima, ya que podr´ıa generar dificultades al modelo al evaluar una oraci´on de la misma categor´ıa. Por esta raz´on, resulta conveniente emplear para el entrenamiento cl´ausulas que compartan el mismo significado pero que est´en redactadas de manera diferente. Con el prop´osito de abordar esta problem´atica, se recurre a ChatGPT para modificar la estructura sint´actica de las frases repetidas, manteniendo su significado sem´antico y proporcionando al modelo una mayor variedad de oraciones. Por ejemplo, las pr´oximas dos cl´ausulas conceden un derecho al cliente, cada una relacionada con un servicio y un calendario temporal diferente. Sin embargo, presentan una similitud excesiva. Por esta raz´on, aprovechamos la respuesta de ChatGPT que nos ofrece otra alternativa sint´actica pero conservando el significado: Cl´ausula 1: “If Verizon fails to meet the Network Latency Service Level in a calendar month for North American and Transatlantic, Customer may request a credit for that month”. Cl´ausula 2: “If Verizon fails to meet the Network Packet Delivery Service Level in a calendar month, Customer may request a credit for that month”. Respuesta de ChatGPT refraseando la cl´ausula 2: “Should Verizon be unable to meet the Network Packet Delivery Service Level within a given calendar month, the Customer is entitled to request a credit for that specific month”. 47 Figura 4.4: N´umero de oraciones por categor´ıa Por ´ultimo, los conjuntos de datos1obtenidos son cargados en Hugging Face para poder utilizarlos de manera sencilla en el c´odigo fuente. Realizando un breve an´alisis cuantitativo y cualitativo de los datos en su estado original, el diagrama representado en la figura 4.5 ilustra las obligaciones y derechos de los actores en el 20 % de los acuerdos utilizados para el conjunto de datos. Este diagrama representa una muestra de los datos que podr´ıan derivarse de la anotaci´on de SLAs. Se puede observar que la mayor´ıa de las cl´ausulas definidas en los acuerdos corresponden a obligaciones, aproximadamente entre 7 −8 oraciones por acuerdo, mientras que los derechos promedian entre 4 −5. Adem´as, se aprecia que los proveedores tienden a tener m´as obligaciones, mientras que los clientes presentan un mayor n´umero de derechos. Una vez que se dispone del conjunto de datos, se procede a llevar a cabo el ajuste de los modelos de manera uniforme. La primera fase se enfoca en la b´usqueda de los hiperpar´ametros m´as apropiados para adaptar los modelos. SetFit proporciona soporte para completar esta tarea mediante m´etodos especializado para la b´usqueda. Concretamente, lo ´unico necesario es la instanciaci´on del modelo que se emplear´a en el proceso de entrenamiento y la definici´on del espacio de b´usqueda de los hiperpar´ametros. Con el objetivo de evaluar el desempe˜no de los modelos en diferentes condiciones, SetFit permite la modificaci´on de varios campos. En este contexto, se analizan los resultados obtenidos al variar el n´umero de iteraciones y etapas, as´ı como el tama˜no del lote y la tasa de aprendizaje. Estos detalles pueden observarse en la tabla 4.1. Despu´es de intentar ejecutar 20 combinaciones posibles de hiperpar´ametros, se 1https://huggingface.co/datasets/marmolpen3/slas-obligations-rights-sentences 48 Figura 4.5: Total de obligaciones y derechos por actor ha observado que tanto el tama˜no como las caracter´ısticas del modelo influyen en la velocidad de este proceso, tal y como se esperaba. De hecho, el modelo all-roberta-large- v1 agota todos los recursos gratuitos de Google Colab. Google menciona que el entorno incluye una GPU NVIDIA T4 con una memoria RAM de 15.0 GB disponibles, sin embargo, opera con un l´ımite de uso din´amico que no es fijo. Adem´as, no se ha verificado que los recursos ofrecidos sean exactamente de dicho tama˜no. Debido a esta limitaci´on, se toma la decisi´on de realizar tres ajustes del modelo con diferentes conjuntos de hiperpar´ametros como parte de una b´usqueda manual, y se selecciona aquel que consiga los mejores resultados. En el resto de b´usquedas, se observa que la tasa de aprendizaje es el factor de mayor relevancia en el ajuste de los modelos. Finalmente, los valores que obtienen el rendimiento m´as ´optimo en la b´usqueda de los hiperpar´ametros son los que se emplean en el entrenamiento de cada uno de los modelos. Es importante mencionar que la m´etrica utilizada para evaluar el rendimiento del modelo seg´un los par´ametros es la medida por defecto en SetFit, conocida como exactitud (Accuracy), que relaciona las predicciones correctas realizadas por el modelo con el total de predicciones efectuadas. En otras palabras, mide el porcentaje de casos en los que el modelo ha realizado predicciones correctas. No obstante, es importante tener en cuenta que esta m´etrica puede ser enga˜nosa dependiendo de la distribuci´on de ejemplos de cada categor´ıa. En este contexto, todas las categor´ıas cuentan con la misma cantidad de cl´ausulas, por lo tanto, aunque no es la medida ´optima, puede tener sentido aplicarla. Al disponer de los hiperpar´ametros, como se detalla en la tabla 4.2, se procede al 49 Cl´ausula Tipo Actor detectado Claims under this Service Level Agreement for SAP Cloud Services must be made in good faith and by submitting a support case within thirty (30) business days after the end of the relevant Month in which SAP did not meet the System Availability SLA Obligation Customer SAP will provide to customers a monthly report describing the System Availability percentage for the applicable SAP Cloud Service either (. . . ) Obligation SAP 99.5 % System Availability percentage during each Month for productive versions Obligation SAP SAP will provide Customer reasonable notice without undue delay of any major upgrades or emergency maintenance to the SAP Cloud Services Obligation SAP Customer may claim a credit in the amount described in the table of Section 3.2 below in case of SAP’s failure to meet the System Availability SLA Right Customer Customer may apply to a future invoice relating to the SAP Cloud Service that did not meet the System Availability SLA Right Customer SAP can use the following maintenance windows for Scheduled Downtimes as listed below Right SAP Tabla 4.4: Obligaciones, derechos y actores del SLA de SAP 56 4.2.3. Razonamiento autom´atico El prop´osito del an´alisis de la informaci´on obtenida del acuerdo es calcular un conjunto de m´etricas que nos permitan examinar el acuerdo desde una perspectiva legal. Esto quiere decir, que faciliten a las partes a comprender a qui´en se beneficia m´as con el acuerdo, si la suscripci´on a los servicios tiene un impacto negativo en el negocio, o si ambas partes disponen de responsabilidades justas y suficientes. En conclusi´on, se identifican tres conceptos que pueden mejorar la relaci´on entre las partes si se tienen en cuenta: los beneficios, las responsabilidades y los riesgos. El concepto de beneficio es amplio y complejo de medir, ya que cada individuo puede tener diferentes criterios para determinar si algo es beneficioso o no. En este contexto, surge una pregunta: ¿Qui´en de las partes involucradas en el acuerdo, ya sea el proveedor o el cliente, obtiene mayores beneficios? Si el equilibrio no se sit´ua en un reparto del 50/50, es posible que exista un desequilibrio entre las partes, y una de ellas se vea favorecida en el contrato. Por ejemplo, una forma de evaluar el beneficio en el acuerdo puede ser a trav´es del an´alisis del conjunto de derechos que tienen cada parte. En relaci´on a las responsabilidades de las partes, es esencial reconocer que su existencia es fundamental para que el contrato tenga sentido. Por esta raz´on, surgen preguntas acerca de posibles lagunas de responsabilidades: ¿Hay alguna parte exenta de responsabilidades en el acuerdo? ¿Existen compromisos que no se tienen en cuenta? ¿Las obligaciones establecidas son ambiguas? La ausencia de responsabilidades en el acuerdo suele indicar la omisi´on de obligaciones esenciales. Por ejemplo, que el proveedor no se comprometa a cumplir con ciertas m´etricas que eval´uan el rendimiento del servicio. Al contratar un servicio, los clientes suelen confiar en aquello que el proveedor est´a dispuesto a proporcionar, a veces sin considerar si el proveedor documenta en el contrato todos los compromisos y derechos pertinentes. Esta falta de conocimiento, combinada con el rendimiento real de los servicios contratados, puede tener un impacto negativo en la continuidad del negocio y en la capacidad del cliente para hacer valer sus derechos. Ante esta situaci´on pueden surgir ciertas preguntas como: ¿Qu´e impacto tiene la firma del contrato en el negocio? ¿Qu´e ocurre si el servicio no est´a disponible? ¿C´omo podemos ponernos en contacto con el proveedor? Esto lleva al cliente a considerar posibles escenarios desfavorables y los recursos legales que tiene a su disposici´on para abordarlos. Por ejemplo, supongamos que el servicio no est´a disponible durante tres d´ıas, siendo un recurso esencial para el funcionamiento del negocio. El proveedor podr´ıa estar comprometido a ofrecer una compensaci´on al cliente, o no. Aquellos acuerdos que incluyan al menos alguna forma de compensaci´on ofrecen una medida de seguridad adicional. Estos aspectos no son determinantes para rechazar la suscripci´on a un servicio en la nube, pero si deben tenerse en cuenta. Adem´as pueden servir como caracter´ısticas para comparar los SLAs de diferentes proveedores. El desaf´ıo actual se encuentra en c´omo evaluamos autom´aticamente estos t´erminos en el contexto de los sistemas inform´aticos. Idealmente, ser´ıa deseable contar con un organismo que evaluara el impacto de las obligaciones y derechos, y que, adem´as, junto con un sistema capaz de comprender las cl´ausulas clasificadas, se pudiera realizar un razonamiento complejo. Esto permitir´ıa 57 evaluar qu´e oraciones de´onticas faltan o si son perjudiciales para alguna de las partes, e identificar compromisos del acuerdo que no est´an contemplados, entre otros aspectos. Por este motivo, se proponen una serie de preguntas que pueden ayudar tanto al cliente como al proveedor a analizar si el acuerdo es adecuado y beneficioso para ambas partes, tomando como referencia las obligaciones y derechos extra´ıdos por iCan. ¿El proveedor tiene obligaciones establecidas en el acuerdo? ¿El cliente dispone de derechos definidos en el acuerdo? ¿El proveedor se compromete a cumplir con valores espec´ıficos de indicadores concretos, como disponibilidad del servicio, tiempo de respuesta, capacidad, escalabilidad, u otros, que permitan evaluar el rendimiento del servicio? ¿El cliente cuenta con canales para comunicarse con el proveedor en caso de problemas? ¿El cliente tiene derecho a asistencia puntual, o el proveedor est´a obligado a prestar ayuda al cliente? ¿El cliente posee alg´un derecho en caso de que el proveedor incumpla el acuerdo? Una versi´on m´as amplia del cat´alogo de preguntas que podr´ıa resultar ´util en el an´alisis autom´atico de CAs, se encuentra en el trabajo presentado en las XVII Jornadas de Ciencias e Ingenier´ıa de Servicios [32]. En este, aportamos un cat´alogo de 37 operaciones de an´alisis que recopilamos de diferentes fuentes. Estas preguntas est´an dise˜nadas espec´ıficamente para reflexionar sobre los t´erminos de uso, y provienen de art´ıculos de investigaci´on centrados en la automatizaci´on de acuerdos, plataformas comerciales y operaciones de an´alisis propuestas por los autores. 4.2.4. Arquitectura del sistema El sistema implementa una arquitectura cliente-servidor especializada que se estructura en tres capas y se integra con tres componentes externos que son claves para brindar el soporte adecuado a las funciones requeridas (ver figura 4.9). La capa frontend5consiste en una aplicaci´on de cliente desarrollada en React, encargada de mostrar informaci´on al usuario y facilitar la interacci´on con el sistema. Este subsistema se comunica con el backend6a trav´es de una API Rest definida. El backend, por su parte, conecta la capa l´ogica o de negocio con la capa de acceso a la base de datos. La capa de negocio es responsable de ejecutar las funciones que corresponden seg´un las acciones realizadas por el usuario y de interactuar con componentes externos para llevar a cabo las tareas requeridas. La capa de acceso a la base de datos se encarga de definir los recursos del sistema. As´ı, mediante la interfaz conocida como modelo, la capa l´ogica interact´ua y opera con MongoDB. Respecto a los recursos externos, contamos con el modelo de´ontico empleado para la clasificaci´on de las oraciones. Este modelo se implementa, entrena y despliega 5https://github.com/marmolpen3/iCan-client 6https://github.com/isa-group/iContracts 58 haciendo uso de los recursos disponibles en la plataforma Hugging Face, que act´ua como biblioteca y repositorio de aprendizaje autom´atico. El modelo se basa en la arquitectura Transformer, lo que le permite capturar de manera efectiva las relaciones y dependencias entre las palabras presentes en el texto. Su entrenamiento se ha enfocado espec´ıficamente en la detecci´on de oraciones que expresan obligaci´on y derecho. En cuanto a la detecci´on del actor, se lleva a cabo utilizando el modelo GPT- 3.5 turbo, que se considera un componente externo en el sistema. Este modelo tiene la capacidad de comprender y generar lenguaje natural, lo que le permite abordar la tarea de extraer el sujeto de la oraci´on y generar una respuesta adecuada en funci´on de la entrada proporcionada. UI Layer Business Layer System Deontic Model GPT-3.5 turbo Data Access Layer API Rest Figura 4.9: Arquitectura del sistema iCan 4.2.5. iCan El sistema iCan simplifica el an´alisis de SLAs a trav´es de una interfaz amigable y f´acil de utilizar que automatiza parte del proceso al detectar cl´ausulas que indican obligaciones, derechos y sus respectivos actores. Como se indica en la arquitectura del sistema, en la secci´on 4.2.4, est´a compuesto por una API sencilla que consta de 5 endpoints que permiten: a˜nadir un acuerdo para identificar las cl´ausulas de´onticas, detectar el sujeto, obtener todos los acuerdos analizados, explorar cada uno de ellos y eliminarlos. Por otro lado, se dispone de una interfaz que permite realizar todas est´as funciones de manera interactiva. Inicialmente, la herramienta presenta los acuerdos que han sido previamente analizados, es decir, aquellos a los que se les han extra´ıdo las obligaciones, derechos y posiblemente los actores responsables de las acciones. Adem´as, en esta interfaz es posible agregar un nuevo SLA para iniciar el proceso de an´alisis (ver Figura 4.10). El formulario para a˜nadir un nuevo SLA es sencillo, permitiendo ingresar un fragmento del acuerdo en un campo de texto b´asico o adjuntar un documento PDF (ver Figura 4.11). Una vez completado el proceso de detecci´on de obligaciones y derechos, es posible consultar los actores que deben llevar a cabo cada acci´on (ver Figura 4.12). 59 Finalmente, los resultados de la herramienta se presentan como se muestra en la Figura 4.13, una lista que enumera las obligaciones, los derechos y los sujetos identificados por los modelos. Figura 4.10: P´agina inicial iCan Figura 4.11: Formulario para a˜nadir un nuevo acuerdo 60 Figura 4.12: An´alisis del acuerdo y posibilidad de identificar los sujetos Figura 4.13: Resultados de iCan 61 4.3. Retos El procesamiento de lenguaje natural est´a experimentando un r´apido crecimien- to y su aplicaci´on se est´a extendiendo a diversas ´areas. Sin embargo, la creaci´on de algoritmos cada vez m´as grandes y potentes dificulta su comprensi´on debido a la gran cantidad de operaciones matem´aticas que involucran y que resulta imposible replicar de manera manual. Explorar en detalle c´omo funcionan estos modelos representa un desaf´ıo. Por otro lado, durante el proceso de entrenamiento, existen factores modificables que pueden haber influido en los resultados obtenidos. La elecci´on de hiperpar´ametros, la calidad y cantidad de los datos de entrenamiento, as´ı como la arquitectura del modelo pueden contribuir en la eficacia del sistema. Explorar y ajustar estos factores es un reto continuo para garantizar resultados m´as precisos y generalizables. De hecho, el conjunto de datos empleado en el ajuste de los modelos de la prueba de concepto han sido clasificados manualmente. Esta clasificaci´on manual es probable que contenga errores. Para mitigar esta amenaza, se propone como mejora futura la exploraci´on de la validaci´on por parte de terceros expertos en el tema, adem´as de llevar a cabo una revisi´on exhaustiva de los conjuntos de datos empleados. Esto permitir´a aumentar la confiabilidad y robustez de los resultados obtenidos. Otro aspecto a considerar es la posibilidad de utilizar otros modelos pre-entrenados que hayan sido espec´ıficamente entrenados con textos legales, pues esto podr´ıa mejorar el rendimiento del modelo tras la adaptaci´on. Asimismo se puede estudiar la resoluci´on del problema mediante diferentes tareas de NLP, m´as all´a de clasificaci´on. Por ejemplo, la incorporaci´on de modelos codificador-decodificador como T5 podr´ıa permitir abordar problemas adicionales y resolver cuestiones m´as complejas en el an´alisis de acuerdos legales. 4.4. Conclusiones En este cap´ıtulo, se han presentado y detallado los componentes que conforman una soluci´on parcial al problema identificado en la secci´on 1.4. El prop´osito fundamental de esta propuesta de soluci´on ha sido demostrar la viabilidad de agilizar y mejorar el proceso de an´alisis de acuerdos mediante el uso de t´ecnicas de NLP. Este estudio ha conseguido avances notables en la exploraci´on de los CAs, construyendo las bases para lo que podr´ıa evolucionar en un razonador autom´atico dedicado al an´alisis de acuerdos. Sin embargo, es fundamental destacar que a pesar de estos logros, existen limitaciones en varios aspectos. Por ejemplo, el conjunto de datos disponible es reducido, lo que afecta a generalizar en la adaptaci´on de los modelos. Asimismo, la aplicaci´on de SetFit, al ser un Framework innovador con una t´ecnica de entrenamien- to de aprendizaje contrastivo, ha mostrado cierta tendencia al sobreajuste. Aun as´ı, la soluci´on obtenida parece alcanzar resultados prometedores, que pueden explorarse, refinarse y mejorarse con nuevos conjuntos de datos o t´ecnicas. 62 Por otro lado, el uso del modelo GPT-3.5 turbo ha sido una soluci´on acertada para la detecci´on del actor. Si bien es cierto que existen posibles mejoras como por ejemplo la aplicaci´on de un modelo espec´ıfico para resolver esta tarea concreta, esta soluci´on resulta interesante como punto de partida. Finalmente, como un paso significativo para la aplicaci´on pr´actica esta soluci´on, se ha desarrollado un sistema b´asico que ofrece una interfaz intuitiva para evaluar cualquier SLA. Mediante esta interfaz, se pueden extraer con facilidad las obligaciones, derechos y actores responsables de las acciones, con el prop´osito de facilitar el uso efectivo del modelo en situaciones del mundo real. 63 5. Validaci´on 5.1. Introducci´on Con esta validaci´on, se busca evaluar el rendimiento de iCan en comparaci´on con otras herramientas disponibles para el an´alisis autom´atico de obligaciones y derechos en SLAs. Espec´ıficamente, se comparar´an los resultados obtenidos por el modelo de lenguaje Chat GPT, el marco de trabajo desarrollado por Natalona et al. [15], y nuestro enfoque de soluci´on, iCan. La prueba que se realiza es la identificaci´on de cl´ausulas de´onticas y de los responsables de llevar a cabo las acciones estipuladas en el SLA proporcionado por la compa˜n´ıa Digital Realty en relaci´on a sus servicios. Puesto que uno de los objetivos principales de este proceso es evaluar los resultados obtenidos al analizar autom´aticamente el acuerdo anterior en cada una de las herramientas de la comparativa, se toma como criterio de evaluaci´on las cl´ausulas identificadas manualmente. Bas´andonos en este criterio, se pueden analizar las desviaciones en la detecci´on de las cl´ausulas obtenidas por cada uno de los sistemas. Por este motivo, se realiza una comparativa en la que se discuten los resultados obtenidos entre las diferentes herramientas, cuantificando la precisi´on de cada una de ellas en t´erminos de aciertos. Pudiendo seleccionar cu´al de ellas se aproxima al criterio de evaluaci´on establecido. 5.2. An´alisis del SLA de Digital Realty Digital Realty es una plataforma l´ıder en proporcionar soluciones de infraestructura y centro de datos, permitiendo a las empresas unir la tecnolog´ıa y los datos de manera que se transformen en inteligencia. La compa˜n´ıa est´a especializada en proveer gran variedad de soluciones sobre centros de datos, contando con recursos flexibles, seguros y escalables alrededor de todo el mundo. Los centros de datos est´an dise˜nados de forma que cumplan con la seguridad necesaria para proteger los datos de los clientes, y adem´as, sean lo m´as ecol´ogicos posibles. Ofrecen una gran variedad de soluciones, como suites personalizadas hasta centros de datos completos configurables. Por otro lado, disponen de un potente sistema de interconexi´on que permite a los clientes combinar los servicios ofrecidos con los de otros proveedores en la nube, entre ellos con sus colaboradores como AWS, Google, IBM, Oracle, Nvidia o Microsoft Azure. La contrataci´on de los servicios se debe realizar contactando directamente con la empresa, optando as´ı a los servicios realmente necesarios en base a las necesidades del cliente. En relaci´on al SLA que establece los t´erminos y condiciones espec´ıficos de los servicios que se est´an ofreciendo, parece haber falta de claridad acerca del acuerdo actual disponible. Para confirmar su vigencia, ser´ıa necesario comunicarse con el proveedor y 64 consultar si existen versiones recientes. Por este motivo, se ha adjuntado como anexo A.2 el documento base obtenido de su sitio web. El prop´osito de este anexo es permitir la replicaci´on de la validaci´on realizada, ya que el mencionado SLA es el que se ha empleado como ejemplo para llevar a cabo el an´alisis de detecci´on de obligaciones y derechos. El acuerdo de nivel de servicio a analizar se aplica en relaci´on a los servicios de colocaci´on, interconexi´on, tr´ansito IP y servicios en la nube. En este se definen una serie de obligaciones y derechos para cada una de las partes. En concreto, uno de los aspectos que se determina es la posibilidad que tienen ambas partes de notificar cualquier condici´on que afecte a los servicios. En caso de una incidencia que interrumpa el servicio, ser´a necesario reclamarlo poni´endose en contacto con el centro de operaciones. Una vez que el proveedor determina que la situaci´on producida ha afectado al servicio, deber´a compensar al cliente a trav´es de una serie de cr´editos. Se menciona que existen dos tipos de cr´editos, los proactivos que son procesados autom´aticamente y los no proactivos que deben ser solicitados por el cliente. En esta situaci´on de interrupci´on el cliente podr´a dar de baja un servicio afectado en un plazo de 30 d´ıas tras el suceso. En el acuerdo tambi´en se especifican los eventos que provocan interrupci´on en el servicio pero que no se tienen en cuenta en el calculo de la indisponibilidad, ya sea por ser situaciones programadas o factores fuera del alcance del proveedor. Por otro lado, se especifica la existencia de un intervalo de instalaci´on en el que el proveedor debe cumplir con los intervalos definidos en la Gu´ıa de Recursos del cliente. Este intervalo finaliza cuando los servicios est´en disponibles y comience la facturaci´on. En este momento, el proveedor har´a esfuerzos comerciales por garantizar que los servicios est´en disponibles en todo momento. Por ´ultimo, los niveles objetivos de nivel de servicio tanto de la instalaci´on como de la disponibilidad del servicio, as´ı como los remedios y las compensaciones por interrupci´on son espec´ıficos de cada uno de los productos proporcionados. Estos valores se publican en el portal del cliente en el sitio web de Digital Realty. Para facilitar la comprensi´on de las obligaciones y derechos seleccionados en el acuerdo, se adjunta el PDF como figura 5.1 con las cl´ausulas resaltadas en verde cuando, a nuestro juicio, indican un derecho, y en rojo cuando parecen ser una obligaci´on. En el margen derecho del documento se especifica el sujeto que debe llevar a cabo la acci´on en el orden en el que aparece cada una de ellas. Para decir el actor correspondiente nos basamos en la estructura de la oraci´on y en la categor´ıa que se ha seleccionado. Esto se debe a que en ocasiones, se observa que las obligaciones del proveedor parecen ser derechos para el cliente, y viceversa, lo que podr´ıa generar confusi´on. De manera general, los resultados que se obtienen en el an´alisis manual son un total de 12 cl´ausulas que indican obligaci´on y de 4 oraciones que reflejan un derecho. 65 5.2.4. Comparativa de resultados La comparativa de los resultados se realiza tomando como criterio de evaluaci´on el an´alisis realizado manualmente. Es decir, se comparan los derechos y deberes identificados manualmente con los detectados por las diferentes herramientas empleadas. Del mismo modo, se lleva a cabo con los responsables determinados para realizar cada una de las acciones coincidentes. Como consecuencia de este estudio, se detecta que iCan tiene una mayor exactitud en comparaci´on con el resto de los sistemas en lo que respecta al total de cl´ausulas detectadas y las que realmente fueron reconocidas como correctas, observar figura 5.5. Figura 5.5: Comparativa entre los positivos correctos y los valores detectados Tomando como referencia las oraciones extra´ıdas de manera manual, podemos observar el n´umero de oraciones de ambas categor´ıas que las herramientas no son capaces de identificar. Por este motivo, cada una de las barras de la figura 5.6 representan las cl´ausulas correctas que se detectan seg´un el procedimiento empleado y para cada una de las categor´ıas disponibles. A pesar de que se observa que iCan es el que obtiene los mejores resultados, casi es capaz de detectar todas las oraciones que indican obligaci´on y derecho en el acuerdo, y adem´as, cometiendo un error de 4 proposiciones detectadas incorrectamente; el resto de las aproximaciones tambi´en obtienen soluciones apropiadas, aunque sus falsos positivos son considerablemente mayor, siendo 8 oraciones con Chat GPT y 10 con Natolana. Otro an´alisis interesante a realizar en la comparativa entre los sistemas empleados es la capacidad de identificaci´on del actor. En este caso, se emplean las oraciones que han sido clasificadas correctamente en cada uno de los procedimientos, y se eval´ua si el responsable coincide con lo determinado manualmente. Los resultados se muestran gr´aficamente en la figura 5.7. Una de las reflexiones que podemos realizar es que detectar al sujeto responsable de realizar las diferentes acciones a trav´es de patrones sint´acticos resulta complejo. En la mayor´ıa de las ocasiones, el framework propuesto por Natolana et al., directamente no es capaz de identificar a ning´un actor debido al alto n´umero de sentencias escritas en voz pasiva, como se puede observar en la figura 5.3 que representa los resultados obtenidos por Natolana. Otra conclusi´on que se puede extraer es que los modelos generativos son exhaustivos al identificar al responsable de cada una de las 72 cl´ausulas, ya que tanto Chat GPT como iCan son capaces de determinar correctamente los actores en la mayor´ıa de las proposiciones, obteniendo un menor n´umero de falsos negativos. Figura 5.6: Comparativa entre el n´umero de cl´ausulas detectadas correctamente Figura 5.7: Comparativa entre el n´umero de actores identificados correctamente 73 5.3. Amenazas a la validez Existen factores que pueden influir en la validaci´on presentada, lo que plantea diversos desaf´ıos a abordar en futuras investigaciones. La validaci´on que se ha efectuado en este TFM es una propuesta inicial, en la que se realiza una comparativa de los resultados que obtienen diferentes herramientas al analizar autom´aticamente el SLA de Digital Realty, tomando como criterio de evaluaci´on en an´alisis manual del mismo. Esto presenta una serie de limitaciones claras que se describen a continuaci´on. En primer lugar, al basar la validaci´on en un ´unico acuerdo, existe el riesgo de que las conclusiones obtenidas no sean aplicables de manera generalizada si se ampl´ıa la muestra. En segundo lugar, el uso del an´alisis manual como criterio de evaluaci´on no se considera una medida del todo fiable, ya que est´a sujeto al conocimiento subjetivo de los investigadores. Por este motivo proponemos dos retos que podr´ıan mitigar est´as amenazas. En primero de ellos, se sugiere evaluar la propuesta con un conjunto diversificado de SLAs que abarquen diferentes tipos de servicios y presenten t´erminos y condiciones variados. En segundo lugar, se recomienda aplicar validaci´on cruzada para la identificaci´on manual de obligaciones y derechos en los acuerdos que se empleen, asegurando que las cl´ausulas detectadas manualmente son las adecuadas. 5.4. Conclusiones En este cap´ıtulo, se ha evaluado el rendimiento de iCan frente a otras herramientas disponibles a la hora de identificar las obligaciones, derechos y actores responsables en el SLA de Digital Realty, empresa especializada en proporcionar centros de datos. Para realizar la comparativa, se presentan visualmente los resultados obtenidos por cada uno de los sistemas al realizar el an´alisis autom´atico del acuerdo. Las conclusiones obtenidas en la comparativa se resumen en que el sistema que m´as se acerca a los resultados conseguidos en el an´alisis manual es iCan, capaz de detectar correctamente todas las cl´ausulas que indican obligaci´on y 3/4 proposiciones que reflejan derecho. Observ´andose buen comportamiento al determinar los responsables de cada una de las acciones. Por otro lado, el sistema que le sigue es Chat GPT que ofrece un an´alisis muy positivo, logrando determinar un buen n´umero de proposiciones de´onticas y extrayendo correctamente el actor. Finalmente los peores resultado son los de Natolana, que a pesar de ser capaz de hallar correctamente bastantes oraciones, el reconocimiento del actor ha sido nulo. 74 6. Conclusiones y trabajo futuro Con este trabajo se pretende demostrar la relevancia que posee el acuerdo de cliente en la relaci´on contractual entre las partes implicadas. As´ı como justificar la necesidad de un sistema que automatice el an´alisis del mismo, con el prop´osito de disminuir errores, ahorrar tiempo y facilitar la comparaci´on entre acuerdos provenientes de distintos proveedores. Pues, a pesar de la existencia de soluciones previas, algunas de ellas presentan limitaciones debido a las t´ecnicas que utilizan para la extracci´on de informaci´on del acuerdo. En este marco, se presenta una propuesta funcional para la automatizaci´on del an´alisis de SLAs, permitiendo extraer las obligaciones, los derechos y los responsables de cada una de las acciones que indican las cl´ausulas detectadas. Este proceso es posible a trav´es del sistema iCan, que mediante el uso de LLMs es capaz de identificar esta informaci´on del acuerdo. El modelo utilizado para detectar las cl´ausulas de´onticas es SetFitmpnet 1, mientras que para determinar qui´enes son los responsables de llevar a cabo las distintas acciones se emplea GPT-3.5 Turbo [29]. La evaluaci´on del sistema se realiza comparando los resultados del an´alisis autom´atico del SLA de Digital Realty con diferentes herramientas. Concretamente, se comparan las conclusiones obtenidas por el modelo de lenguaje Chat GPT, el marco de trabajo desarrollado por Natalona et al. [15], y nuestro enfoque de soluci´on, iCan. En la evaluaci´on de los resultados obtenidos se refleja que iCan es capaz de detectar las obligaciones y derechos mejor que el resto de sistemas actuales en base al criterio de evaluaci´on definido. Logrando identificar el 100 % de las obligaciones detectadas manualmente y 3 de los 4 derechos. Adem´as, con una mayor precisi´on y exhaustividad que el resto de las aproximaciones. Nuestros avances en esta ´area nos han permitido identificar posibles mejoras y l´ıneas de investigaci´on futuras que debemos explorar. A continuaci´on, mencionamos las principales direcciones que nos generan gran inter´es en cuanto a futuras l´ıneas de trabajo. Recopilaci´on de grandes cantidades de datos, clasificados y sin clasificar. Los datos son un elemento esencial en el desarrollo de este trabajo. Actualmente, para esta prueba de concepto se ha generado un dataset limitado y sesgado a nuestro conocimiento. Es por ello, una vez que se ha comprobado la viabilidad de la propuesta a la hora de extraer informaci´on de los acuerdos, un trabajo de gran inter´es es participar con expertos legales en la b´usqueda y clasificaci´on de datos legales que permitan mejorar el conocimiento del modelo. Esta aproximaci´on podr´ıa mejorar y ampliar las tareas que puede resolver el modelo. Definici´on de operaciones de an´alisis y m´etricas de medici´on. Una de las limitaciones actuales es que los acuerdos son dif´ıcilmente comparables entre s´ı, esto se debe a la libertad legal del proveedor de dise˜nar los contratos con las cl´ausulas que considere seg´un su negocio. Por este motivo contar con preguntas de inter´es tanto para 1https://huggingface.co/marmolpen3/paraphrase-MiniLM-L3-v2-sla-obligations-rights 75 el proveedor como para el cliente pueden disminuir conflictos legales y facilitar a ambas partes a comprender las cl´ausulas definidas. Es por este motivo, que se propone crear con un cat´alogo de operaciones de an´alisis ´optimo que permita a las partes realizar un razonamiento sobre la informaci´on del acuerdo verificando si es correcta y cubre las necesidades del negocio. As´ı como, definir un conjunto de m´etricas cuantificables que permitan medir las caracter´ısticas del acuerdo, facilitando la comparativa de los mismos. Exploraci´on de diferentes alternativas de entrenamiento de modelos. Para el desarrollo de este TFM y su prueba de concepto se ha realizado una adaptaci´on de varios modelos codificadores preentrenados para llevar a cabo tareas de clasificaci´on de oraciones en obligaciones, derechos y ninguna de las anteriores. Con este enfoque se busca profundizar en las capacidades de los modelos y completar entrenamientos supervisados y no supervisados. As´ı como, modelos, que hayan sido anteriormente ajustados con textos legales. Aplicaci´on de la propuesta de soluci´on en proyectos de investigaci´on. El objetivo es extraer las obligaciones y los derechos de los beneficiarios de proyectos de investigaci´on. Estas cl´ausulas se recogen en diferentes documentos que conforman “acuerdos impl´ıcitos que el beneficiario se compromete a cumplir en el momento en el que se acepta la ayuda”. Obtenci´on de mayor informaci´on sobre las obligaciones y derechos detectadas. Expandir la informaci´on disponible sobre las cl´ausulas detectadas permite realizar un razonamiento m´as valioso y consistente. Uno de los objetivos principales es localizar la procedencia de las obligaciones y derechos. Desde un punto de vista pr´actico ayudar´ıa a dar respuesta a preguntas del tipo, ¿De d´onde viene esta obligaci´on? ¿Qui´en es el ´organo/entidad con la capacidad de incorporarla? ¿Cu´ando se incorpor´o por primera vez? ¿Existe alg´un apartado que no cuente con obligaciones? 76 7. Bibliograf´ıa [1] Open AI. Six strategies for getting better results. https: //platform.openai.com/docs/guides/gpt-best-practices/ six-strategies-for-getting-better-results, 2023. Accessed: 19/06/2023. [2] Ilias Chalkidis, Manos Fergadiotis, Prodromos Malakasiotis, Nikolaos Aletras, and Ion Androutsopoulos. LEGAL-BERT: The muppets straight out of law school. In Findings of the Association for Computational Linguistics: EMNLP 2020, pages 2898–2904, Online, November 2020. Association for Computational Linguistics. doi: 10.18653/v1/2020.findings-emnlp.261. URL https://aclanthology. org/2020.findings-emnlp.261. [3] Legal Transition Committee. “Cloud Model Service Level Agreement”. Tech. rep., Funded by the European Commission and implemented by the European Bank, 2020. [4] Hamish Cunningham, Diana Maynard, Kalina Bontcheva, and Valentin Tablan. GATE: A framework and graphical development environment for robust NLP tools and applications. In Proceedings of the 40th Annual Meeting of the Association for Computational Linguistics, Philadelphia, PA, USA, 2002. doi: 10.3115/1073083. 1073112. URL http://www.aclweb.org/anthology/P02-1022. [5] Lucia De Marco, Filomena Ferrucci, Tahar Kechadi, Gennaro Napoli, and Pasquale Salza. Towards automatic service level agreements information extraction. pages 59–66, 04 2016. doi: 10.5220/0005873100590066. [6] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. BERT: pre-training of deep bidirectional transformers for language understanding. CoRR, abs/1810.04805, 2018. URL http://arxiv.org/abs/1810.04805. [7] Real Academia Espa˜nola. Diccionario de la lengua castellana. 23.ªedition, . URL https://dle.rae.es/obligaci%C3%B3n. [8] Real Academia Espa˜nola. Diccionario de la lengua castellana. 23.ªedition, . URL https://dle.rae.es/derecho. [9] Hugging Face. The hugging face course. https://huggingface.co/course, 2022. Accessed: 18/04/2023. [10] WorldCC Foundation. Worldcc contracting principles. https://www.worldcc. com/Portals/IACCM/Files/WorldCC%20Contracting%20Principles%20-% 20October%202022.pdf, 2022. Accessed: 15/06/2023. [11] Rafael Fresno-Aranda, Pablo Fern´andez, and Antonio Ruiz-Cort´es. A catalogue of analysis operations for api pricing plans. In Submited to “XVIII Jornadas de Ingenier´ıa de Ciencia e Ingenier´ıa de Servicios”. SISTEDES, 2023. 77 [12] Isa Fulford and Andrew Ng. Chatgpt prompt engineering for developers, 2023. URL https://www.deeplearning.ai/short-courses/ chatgpt-prompt-engineering-for-developers/. [13] Ruka Funaki, Yusuke Nagata, Kohei Suenaga, and Shinsuke Mori. A contract corpus for recognizing rights and obligations. In International Conference on Language Resources and Evaluation, pages 2045–2053. European Language Resources Association, 2020. [14] Antonio Gamez-Diaz, Pablo Fernandez, and Antonio Ruiz-Cort´es. “An Analysis of RESTful APIs Offerings in the Industry”. In Service-Oriented Computing - 15th International Conference, ICSOC. Malaga, volume 10601, pages 589–604, 2017. [15] Divya Natolana Ganapathy and Karuna Pande Joshi. A semantically rich framework to automate cloud service level agreements. IEEE Transactions on Services Computing, 16(1):53–64, 2023. doi: 10.1109/TSC.2022.3140585. [16] Github. Customer agreement. https://github.com/customer-terms, 2023. Accessed: 19/06/2023. [17] Google. Service level terminology. https://sre.google/sre-book/ service-level-objectives/, 2017. Accessed: 20/06/2023. [18] Risto Hilpinen. Deontic logic. In Lou Goble, editor, The Blackwell Guide to Philosophical Logic, pages 159–182. Oxford, UK: Blackwell, 2017. [19] Zhiheng Huang, Wei Xu, and Kai Yu. Bidirectional lstm-crf models for sequence tagging, 2015. [20] Hugo Roy. Terms of Services. https://tosdr.org/en/frontpage#ratings, 2023. Accessed: 07/05/2023. [21] Scikit learn developers. Classification metric. https://scikit-learn.org/ stable/modules/classes.html#classification-metrics, 2023. Accessed: 30- 06-2023. [22] Scikit learn developers. Multi-class classification metrics. https: //scikit-learn.org/stable/modules/model evaluation.html# multiclass-and-multilabel-classification, 2023. Accessed: 30-07-2023. [23] M. Lippi, P. Palka, G. Contissa, F. Lagioia, H.-W. Micklitz, G. Sartor, and P. Torroni. Claudette: an automated detector of potentially unfair clauses in online terms of service. Artificial Intelligence and Law, 27:117–139, 2019. doi: https://doi.org/10.1007/s10506-019-09243-2. [24] M. Lippi, P. Palka, G. Contissa, F. Lagioia, H.-W. Micklitz, G. Sartor, and P. Torroni. Claudette. http://claudette.eui.eu/demo/index.html, 2023. Accessed: 07/05/2023. [25] Paul McNamara and Frederik Van De Putte. Deontic Logic. In Edward N. Zalta and Uri Nodelman, editors, The Stanford Encyclopedia of Philosophy. Metaphysics Research Lab, Stanford University, Spring 2022 edition, 2022. 78 [26] Carlos M¨uller, Antonio M. Gutierrez, Pablo Fernandez, Octavio Mart´ın-D´ıaz, Manuel Resinas, and Antonio Ruiz-Cort´es. “Automated Validation of Compensable SLAs”. IEEE Transactions on Services Computing, 14(5):1306–1319, 2021. [27] Tim Grance (NIST), Joan Hash (NIST), Marc Stevens (BAH), Kristofor O’Neal (NIST), and Nadya Bartol (NIST). Guide to information technology security services. Technical Report NIST Special Publication (SP) 800-35, National Institute of Standards and Technology, 2003. [28] Open AI. GPT models tasks. https://platform.openai.com/docs/guides/gpt, . Accessed: 15-06-2023. [29] Open AI. GPT-3.5-turbo description. https://platform.openai.com/docs/ models/gpt-3-5, . Accessed: 15-06-2023. [30] J.D. Otto Hanson. Termscout. https://www.termscout.com/, 2023. Accessed: 17-07-2023. [31] Patrick Hsu. Request an extension that reads the Terms and Conditions agreement. https://twitter.com/pdhsu/status/1615059981044441088?s=12& t=aohMYFx2OGhmajYpbxs9XA, 2023. Accessed: 07/05/2023. [32] Elena Molino Pe˜na, Jos´e Mar´ıa Garcia, and Antonio Ruiz-Cort´es. Operaciones de An´alisis sobre los T´erminos de Uso en Customer Agreements. In Proc. XVII Jornadas de Ingenier´ıa de Ciencia e Ingenier´ıa de Servicios. SISTEDES, 2022. URL http://hdl.handle.net/11705/JCIS/2022/041. [33] Elena Molino Pe˜na, Jos´e Mar´ıa Garcia, and Antonio Ruiz-Cort´es. Limitations of current techniques to detect obligations and rights in sla. In Submited to “XVIII Jornadas de Ingenier´ıa de Ciencia e Ingenier´ıa de Servicios”. SISTEDES, 2023. [34] Rackspace. Contract structure. https://www.rackspace.com/information/ legal/contract-structure, 2023. Accessed: 19/06/2023. [35] Nils Reimers and Iryna Gurevych. Sentence-bert: Sentence embeddings using siamese bert-networks. CoRR, abs/1908.10084, 2019. URL http://arxiv.org/ abs/1908.10084. [36] Sebastian Ruder. A Review of the Neural History of Natural Language Processing. http://ruder.io/a-review-of-the-recent-history-of-nlp/, 2018. [37] Abhilasha Sancheti, Aparna Garimella, Balaji Vasan Srinivasan, and Rachel Rudinger. Agent-specific deontic modality detection in legal language, 2022. [38] Miguel Sotaquir´a. Redes Transformer. https://www.codificandobits.com/ blog/redes-transformer/, 2020. Accessed: 05-07-2023. [39] spaCy team. Part-of-speech tagging. https://spacy.io/usage/ linguistic-features#pos-tagging, 2023. Accessed: 20-06-2023. [40] Technical-Committee. “Information technology-cloud computing-service level agreement (SLA) framework-Part 1: Overview and concepts”. Tech. Rep. 19086- 1:2016(E), ISO/IEC, Geneva, Switzerland, 2016. 79 [41] The MathWorks, Inc. Support Vector Machine (SVM). https://es.mathworks. com/discovery/support-vector-machine.html, 2023. Accessed: 17/07/2023. [42] Lewis Tunstall, Nils Reimers, Unso Eun Seo Jo, Luke Bates, Daniel Korat, Moshe Wasserblat, and Oren Pereg. Efficient few-shot learning without prompts, 2022. [43] Antonio Vallecillo and Martin Gogolla. Modeling behavioral deontic constraints using uml and ocl. In Gillian Dobbie, Ulrich Frank, Gerti Kappel, Stephen W. Liddle, and Heinrich C. Mayr, editors, Conceptual Modeling, pages 134–148. Springer International Publishing, 2020. [44] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, and Illia Polosukhin. Attention is all you need, 2017. [45] Georg Henrik Von Wright. Deontic logic: A personal view. Ratio Juris, 12(1): 26–38, 1999. doi: 10.1111/1467-9337.00106. 80 81