Trust
LGOBE http://www.infor.uva.es/~mercedes (M. M. Martínez-González) CEUR
While these formats are both human- and machine-readable, they are not suitable for semantic interoperability, automatic knowledge extraction, or automatic verification. Therefore, current ROPAs are not linked to related or similar documents, their content is not validated, and semantic interoperability is not enabled. On the contrary, citizens should be provided with tools able to extract the knowledge they keep, and show this knowledge to users in understandable manners, which is indeed a GDPR request. ROPAs should not be independent and isolated pieces of information. They should be reliable sources of relevant information, linked, and available for intelligent knowledge extraction. Technology can help to make it possible.
OntoROPA aims at the creation of a ROPA knowledge graph that will include not only the legal requirements, but also the practical knowledge from the community of privacy and data protection experts, including lawyers, legal advisors and scholars, data protection oficers, and rulers who are proficient in the creation and manipulation of ROPAs.
The notion of practical knowledge is crucial because this entails an implicit professional knowledge that must be elicited and made explicit in the knowledge acquisition process. This kind of knowledge is also modelled, as it encompasses the professional selection and understanding of legal normative texts and provisions. This is not to be found in legal documents containing positive law because it belongs to their legal experience. This includes the interpretation of hard law, soft law, policies, and ethics.
In a broad definition, compliance is the conformance of human or artificial behaviour with
a set of rules, norms, principles, or values. In the data economy, compliance has also been
bootstrapped, because if humans must be compliant, so must be autonomous and intelligent
systems (AI/S), socio-technical systems (STS), and socio-cognitive technical systems (SCTS).
Regulatory and legal compliance should be carefully distinguished. Regulatory compliance
refers to the concept, languages and methodologies developed within the business, commercial
and corporate fields to design, control and monitor in advance business processes and activities.
Legal compliance refers to the formal developments that can be deemed ‘legal’ according to
the norms, principles, and jurisdictions of regional, national, international, and transnational
legal systems. They certainly converge, but the meanings of the two notions should be kept
separate, as some requirements must be added for legal compliance be accorded from oficial
bodies. This is linked to the Compliance by Design (CbD) schemes that have been developed
in the corporate business field since the beginning of the century to cope with the constraints
set by the Sarbanes-Oxley Act (2002), a US Federal law that laid down new requirements
for public company boards and accounting firms. There is some confusion in this regard.
In computer science, literature regulatory compliance also denotes “the act and process on
ensuring adherence to laws” that involves “discovering, extracting and representing diferent
requirements from laws and regulations that afect a business process” [
Although most ontology methodologies have been highly influenced by the existing standards
and methodologies regarding software and systems design, few of the revised methodologies
have been deeply influenced by the standards and methods set towards a human-centred
perspective to systems (ontology) design, domain expert-centred design. Most ontology methodologies
may involve domain experts and users at some stages of the development process (mainly
knowledge acquisition and evaluation), although none of the above-mentioned methodologies
describes a complete expert-centred perspective towards ontology engineering. In general,
no reference is made towards ensuring that the knowledge modelled in the ontology is, in
fact, shared amongst the experts or professionals of the domain. Human-centred software
design and user validation are highly standardised processes which include participation in and
evaluation of the general development of software, systems and products, the analysis of their
usability, the documentation provided and the quality of their use. In this project, we take into
account the detailed modelling guidelines from [
Since the enactment of data protection regulations in the European Union and elsewhere, from
the repealed Data Protection Directive (DPD, Directive 95/46/EC of the European Parliament and
of the Council on the Protection of Individuals with Regard to the Processing of Personal Data
and on the Free Movement of Such Data2) to the current General Data Protection Regulation
(GDPR, Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April
2016 on the Protection of Natural Persons with Regard to the Processing of Personal Data
and on the Free Movement of Such Data, and Repealing Directive 95/46/EC3), many have
pursued the encoding of their semantics for the development of smart data privacy compliant
applications. We mainly mention a selection of GDPR-related ontologies that are relevant to our
project that are available for review and reuse. We also focus on their use of expert knowledge
during their development. For extensive accounts of data protection related ontologies see
[
In the last five years, Regtech solutions have been fuelled by the favourable conditions of the
legal market. RegTech is an acronym for ”Regulatory Technologies”. LawTech—regulatory
technologies for law—refers to RegTech, FinTech, InsuTech and SupTech. But RegTech is a
broader concept, used either in the fields of business, law, management and technology. A simple
definition would identify that “RegTech is about the digital tools that are necessary to master
regulatory complexity” [
LawTech has created an expanding legal market, in which companies ofer a variety of legal
services mainly based on AI and machine learning solutions—not just the more traditional
e-discovery but supervision, monitoring and automatic compliance of regulatory systems,
including smart contracts, cryptocurrencies and online dispute resolution. This is a
noncomplete list of automation fields: (i) expert knowledge and compliance; (ii) legal research
(interpretation and resolution of cases), (iii) prediction sentences and cases (legal analytics), (iv)
electronic discovery (e-discovery), and (v) intelligent contracts (smart contracts). However, it still
is a volatile market. Just before the Covid-19 pandemic, LawTech venture capital investments
increased dramatically at the rate of 2.4 new start-ups per day [
The automation of legal documents is the most well-trodden path. Legal compliance is the
least—as it certainly is a more complex relational field because the behaviour of all stakeholders
must be taken into account (not just meaningful texts to be interpreted). There are systems in
legal informatics that have been designed for drafting, storing, organising, consolidating, or
retrieving provisions in plain natural language to eventually support legal decision-making
[
OntoROPA follows the general trend of the legal compliance market presented in section 2.4, but instead of interpreting directly the content of article 30 and article 33 of GDPR (mainly about the duties of controllers), an indirect way of approaching the subject was chosen: 1. Compliance cannot just be a result to be targeted but a process to be engaged with, embedded into a blockchain solution; 2. Compliance through Design (CtD) means that legal interpretation occurs along the whole process, following several steps crossing hard law, policies, soft law, and ethics; 3. Thus, the starting point cannot be a top down nor a bottom-up approach, but a middle-out one, stemming from intermediate legal notions –intellectual property, legal time, security, legal validity, etc.– reaching out to all stakeholders involved in the transactions; 4. In this regard, we are opening a legal procedural way of producing veracity, certainty and especially trust, as consumers, producers and markets will have a mechanism to turn out their Records of Processing Activities (ROPAs) into a legal, acceptable and actionable document; 5. What this latter formulation entails is a certification process that can be accepted by agencies and courts as legal evidence, turning the needle in all directions of the legal compass; 6. In this sense, we do not need to wait for a specific case-based interpretation of what ‘joint controller’ means (there are no available cases yet): stemming from the notions and clusters contained into the documents produced by Data Protection Agencies should be enough to get a good description of oficial implementation patterns; 7. Therefore, as said, the knowledge acquisition process (KAP) should start from the documents and the actual behaviour already in place, and not from any abstract interpretation of how the process should be; 8. The final result of the project lifecycle is a certified ROPA that can be ofered as a legal web service on the iExec platform.
OntoRopa is benefiting from this expanding market of legal web services. The solution for modelling ROPAs fits into the legal compliance modelling landscape, but we think it is simpler, and easier to be understood, accepted, and adopted not just by LawTech companies, lawfirms and corporations, but by oficial drafters, rulers, controllers, and supervisors. There is a need to comply with GDPR requirements. Hence, OntoRopa can be expanded through a variety of legal ecosystems, depending on the private or public field of deployment. Table 1 summarises its goals, which are aligned with the detected issues, and innovation.
The target community of users starts with ROPA providers (ROPA controllers). The OntoROPA ecosystem will support more communities of ROPA users. For example, data protection supervisors can assess ROPAs. Figure 1 summarizes the flow of ROPAs within these communities in OntoROPA. However, citizens are not able to assess ROPAs, but to read and query the information that ROPAs can provide to them about the way their personal data are treated and protected. A general solution, able to support diferent communities, requires a long-term project. The ifnal solution entails the creation of a Law Tech legal web service to provide automated ROPAs to law firms, companies and administrations. This also entails the definition of a business model that fits into the niche of Data Protection and Privacy Services, as advanced by the European Digital Markets strategy.
There are two main components in the OntoROPA project: (i) an OWL ontology that collects the expert knowledge from the target domain (ROPA community) and is the tool directing the inference processes that support validation and trustworthiness; (ii) and the software artifacts that process ROPAs.
OntoROPA proposes the development of a domain ontology formally expressed in OWL that will be ofered as open data, reliable, reusable, and extensible. This professional ontology will support the creation and validation of ROPAs. Validation will be twofold: RDF validation for correctness and OWL validation for completeness. As already stated, the ROPA Ontology does not only include legal but also professional knowledge extracted from the community of privacy and data protection experts—mainly including lawyers, legal advisors and scholars, data protection oficers, and rulers who are proficient in the creation and manipulation of ROPAs.
As a proof of concept, Figure 2 draws the ROPA RDF description which can be validated for correctness, and a preliminary ontology sample that demonstrates the reasoning capabilities for completeness of legal-compliance standard validation. The ontology creation process is based on metadata and competency questions.
OntoROPA uses a modular approach, where each module serves a specific functionality. This modular approach will facilitate OntoROPA resilience to changes in collaborators. For example, we can either take in charge the Identity module with the development of our own oracle, able to validate X5094 digital certificates in LDAP services or to use services provided by external providers and blockchain platforms.
A very important component of OntoROPA are data: ROPAs, ontologies, and data that helps to achieve the desired facilities, such as certificates and credentials used for identity verification. Figure 3 includes the data layer and software modules of OntoROPA. These data are critical for OntoROPA modules: they are inputs and outputs. More important, they determine the design of each module. This is a data-driven design. They can be described as follows: 1. Identity:: Legal compliance requires being able to link responsibilities and authorship to legal entities, real world entities. X.509 certificates will be used. Verification of these certificates requires to query LDAP directories. 2. Linked RDF ROPAs: The OntoROPA project aims to represent ROPA as RDF graphs, linked with the OntoROPA ontology, but also to other ROPAs. RDF, linked data, and related 4X.509 certificates are digital certificates that use the widely accepted international X.509 public key infrastructure (PKI) standard to verify that a public key belongs to the hostname/domain, organization, or individual contained within the certificate.
Semantic Web standards provide the tools to represent, share and manage semantics in technical environments. Storage will rely on the facilities provided by a solution able to store and manage RDF graphs on blockchain. If not possible, an external RDF store, e.g.
AllegroGraph, may be needed. 3. Validation: ROPAs should comply with article 30 of the GDPR2 and with the non-written rules of use that the community of experts, ROPA controllers, follow when they create them. This knowledge is collected in the OntoROPA ontology. The validation will be done against the ontology, using the inference capabilities associated to OWL rules and inference. We would like this validation to be a secure process, not subject to injections. WebProtégé can be used to reach this objective. The proof of validation will be taken in charge of-chain by OntoROPA, with its own signature and certificates. 4. Certification : ROPAs’ origins and provenance should be certified. As for the results of validation, it depends on the viability of secure executions. If the process can be secured in a blockchain TEE, the blockchain enclave signature should reinforce OntoROPA’s signature. 5. Proactiveness: The date in which a ROPA is available matters from a legal perspective.
The immutability properties of blockchain platforms will support this. The transaction associated to the publication will provide proof of proactiveness.
We introduce scenarios as the process of generating a ROPA in the context of the OntoROPA project. For instance, a person responsible of its creation and maintenance in an organization — the data privacy oficer in a given university— needs to create and publish a ROPA to describe personal data treatments in her university. These are the requirements: (i) using standard vocabularies, (ii) making sure that her ROPA includes the right information as required by article 30 of GDPR, and (iii) once this is achieved, publishing it and making it available to other ROPA providers, data protection supervisors, and the public in general (this is mandatory for Public Administrations). Moreover, she wants to be able to give evidence on the publication date if the data protection supervisory authority (in Spain, the AEPD; in France, the CNIL, etc.) launches an inspection after critical situations such as data breaches 5. The data privacy oficer may use the application providing the way of creating a ROPA.
There are two main possibilities: (i) Import ROPA: A ROPA is already available as a pdf or excel sheet. This ROPA is imported; (ii) New ROPA: A ROPA is created from the beginning.
We will elaborate on the second one: A ROPA provider wants to create a new RDF ROPA to describe the activities dealing with personal data. Figure 4 shows an overview of the process lfow: 1. The first step is to create the RDF file describing the ROPA. 2. The second step is to validate the ROPA and check that it contains the right information as requested by the GDPR. 3. Once it is ready for publication, its quality is certified. 4. The certified ROPA is published.
OntoROPA functional requirements are summarised in Table 2. The main functionalities are creating, editing, and deleting a ROPA. But there are also some additional functionalities derived from the goals of providing legal validity to ROPAs: validation, signing, certification. Users who are authorized to create, edit, and publish ROPAs should be able to identify themselves. 5The GDPR sets the obligation of keeping available ROPAs for inspections if required by the data protection supervisor authority. Moreover, it introduces the concept of proactiveness, which means that (i) privacy by default and by design have been applied from the very beginning, (ii) that the security measures have been implemented, and (iii) the information about personal data activities is available. ROPAs are the records collecting this information. Therefore, ROPAs must be available while personal data treatment develops. Some data protection experts are concerned about the possibility that ROPAs are generated after the supervisor’s request.
Legal Compliance is essential in organizations to ensure compliance with their Codes of Conduct, as consumers demand products and services provided with ”ethical and sustainable” behaviours. They often access social networks to publicly denounce those companies that do not meet their commitments, resulting in serious reputational damage and significant sales drops. Noncompliance with these obligations is punished with a range of sanctions ranging from heavy ifnes to professional disqualification or cessation of activity, as well as irreparable reputational damage.
There are three indicators that can help quantify a return on investment in legal compliance: (i) increased competence and eficiency within the organization; (ii) savings by reducing legal risks and prevention of sanctions; (iii) generation of better business opportunities. With automated and standardized toolkits, it becomes easier to meet the requirements of ISO 270016 and ENS (Esquema Nacional de Seguridad)7. ROPA controllers can benefit from having a standard tool to simplify the task of creating their own ROPAs, and the possibility to adapt/extend it to their own use cases.
Legal validity (i.e. ‘legality’) is not equivalent to computational or logical validity. ROPA validation refers to the accuracy, traceability and technical reproductivity of the process that has generated it. It can be reached through the ontology.
However, this is not turning ROPAS into valid processes with legal outcomes and efects. Automated legal validity should be carried out aligning: (i) the selection of relevant legal sources in a transparent, shareable, and acceptable way, according to the main legal doctrine, (ii) the normative interpretation process that is accepted by oficial bodies, such as Data Protection agencies, (iii) as a last resort, the normative interpretation process that is accepted by regional, national, and European judiciaries. There are a variety of normative and regulatory sources that should be considered.
To ease the process of handling them we have defined them into four legal diferent clusters: (i) Hard law (laid down by Parliaments and the Judiciary (this includes European Regulations, such as the GDPR, and the Directives that have been transposed into the national legal systems by the State members); (ii) soft law (such as international agreements and covenants, mandatory after mutual or collective agreements); (iii) policies (issued by European and national governments to developing, enforcing, and implementing Acts, Regulations, and case-based law sentences), (iv) ethical principles and values, as they have been discussed, proposed and accepted in specific sectors (such as the recent EU guidelines for Artificial Intelligence).
Besides legislation, it is worth noting that the legal value–i.e. legal validity–is created through a process that fosters legal security and social trust among all stakeholders in the market (including companies, corporations, administrations and citizens). Then, ISO standards and technical protocols (such as the W3C standards and recommendations) matter. As stated by EU recent strategies, better regulation principles involving Impact Assessments and citizens’ consultations, and the introduction of digital currencies as a basis for the EU digital market fosters the general use of specific policies and best practices that benefit from the experiences already gathered.
OntoROPA embraces the middle-out approach to AI governance set by the AI4People Report
to the EU Parliament (November 2019)8. It can be defined as the middle-ground between
top-down and bottom-up regulatory approaches, fostering co-regulation, co-responsibility and
dialogue between rulers and the subjects of regulation [
It is worth mentioning that law or its digital version, legal governance systems [
This dynamic set constitutes a dimension of human and artificial systems and interfaces. It pervades the software and the data layer from inside out. This is why a middle out approach can be the most appropriate to generate the legal ecosystem that is needed to validate ROPAS and ROPAS’ computational management in both senses—technological and legal. There are two layers—software and data layer—and three dimensions—technological, social, and legal. The links between them occur stemming from the secured process to produce a certified and legally valid ROPA.
The OntoROPA legal ecosystem is generated by the set of technical requirements and social and legal conditions that are taken into account by controllers, supervisors, professional agents in the marketplace (legal web services, law firms and companies). Thus, the certification and validation processes involve the participation of all stakeholders. Again, technical requirements do not reflect per se the social and legal conditions. They are reached through (i) the mutual understanding of regulations, i.e. the shared agreement on the rights and duties set by the regulatory system (legislation, policies, best practices, and ethics), (ii) the mutual understanding of the position of all agents participating in the process, (iii) the mutual understanding of all necessary actions to be taken to make the final product ‘legal’. This is where the legal validity of certification comes from. Certification and validation processes do not stand by their own: They are necessary components of the legal ecosystem generated through the coordination of all required elements, as shown in Figure 6.
The use of blockchain technologies has generated some controversies about its compatibility
with GDPR requirements. Permissionless blockchains are distributed, decentralised
peer-topeer networks in which everyone can participate interacting with unknown counterparties,
trusted or not [
The OntoROPA project is law and data driven. ROPAs are deemed to be a critical piece of legal compliance from a social perspective, for they are the only available source of information accessible to non-technical people (including citizens, judges, rulers, law experts, data protection users, and supervisors). Thus, this fact makes them a critical piece for GDPR compliance for all stakeholders—providers, controllers, supervisors, and companies. This is a market niche. As a result, we figured out a legal governance system that facilitates a soft orchestration of hard law, soft law, ethics, and policies.
This also is work in progress. Some steps have been advanced in the implementation process, e.g. the transformation of ROPAs to designed semantic schemas has been tested, the first version of the ontology has been already built, and some tests with tools that can be used to provide trust have been carried out. There is still room for improvement. The design of blockchain tools, and the implementation of AI algorithms that will validate ROPAs against the ontology will be developed in the next future.
This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 957338, NGI OntoChain - Trusted, traceable and transparent ontological knowledge on blockchain.