Federated compliance is a crucial concept in the realm of generative artificial intelligence (GAI)...
Federated compliance is a crucial concept in the realm of generative artificial intelligence (GAI) and copyright law. Understanding and implementing federated compliance ensures that organizations adhere to legal and ethical standards while avoiding potential pitfalls and legal issues. Federated rules are crucial for interacting with Governance, Risk Management, and Compliance (GRC) and Security Operations (SecOps) tools because they facilitate data integration and provide a unified framework for managing security and governance. This, in turn, enhances organizational efficiency and adherence to regulatory standards.
Understanding the “Federated” Aspect of Compliance
Federate is an intransitive verb that means to form two or more parties into an alliance, to band together, cohere, cooperate, or ally with each other
The following are key concepts regarding federated rules.
- Decentralized Decision-Making—Different stakeholders have their own rules and guidelines that they impose for their products [e.g., authority documents(ADs)] and services [e.g., inputs/outputs that each independent service vendor (ISV) provides in GRC and SecOps tools]. Where possible, they develop common rules or at least abide by a suite of common rules established by other means.
- Collaborative Standards—The stakeholders abide by common standards agreed upon by all members. These standards address what artificial intelligence systems can and cannot do concerning copyrighted materials.
- Dynamic and Adaptive—Federated rules are not static; they can be updated as technology evolves and new issues arise.
In the world of compliance, federation comes into play in two areas—(1) what we must comply with and (2) the tools we use to implement and prove compliance.
Federated Rules Surrounding GAI and ADs
What we comply with are ADs. There are rules we need to understand about what we can do with their content when implementing their mandates. These rules apply from the moment we download them into our organization and continue when those mandates are transformed into controls and audit questions. The point is there is not a single set of rules about what we can and cannot do; therefore, we must look at these rules and form a “federated patchwork” of what we can and cannot do with the content. So, let us start with the beginning of compliance—the ADs that tell us what to do. Why? Because someone in your organization will want to search those documents and then leverage their contents using some form of GAI.
Your organization is most likely surrounded by a suite of ADs you must follow—documents created by public and private organizations.
A suite of authors of ADs
ADs fall within distinct categories of copyright protections. The most open are documents in the public domain. The most closed are documents with stated copyright restrictions. Between those two extremes are ADs that subscribe to either the Creative Commons structure or the newer Federated Data License structure. The following are the categories in which ADs are placed.
| AD Type | License Type |
|---|---|
| Regulations | Public Domain |
| Regulatory Directives or Guidance | Public Domain |
| Contractual Obligations | Non-Disclosure Restricted |
| International or National Standards | Public Domain |
| ISO and BSI Standards | Copyright Restricted |
| Audit Guidelines | Public Domain or Copyright Restricted |
| Safe Harbors | Public Domain or Copyright Restricted |
| Best Practice Guidelines | Creative Commons or Copyright Restricted |
| Vendor Documentation | Creative Commons or Copyright Restricted |
| Organizational Governance Documents | Non-Disclosure Restricted |
At the outset, you need to know what you are and are not allowed to do with the content of the ADs you must implement. Chances are, you will have both unrestricted and restricted documents in your compliance library. If so, your rules are now federated.
Federated Rules surrounding GRC and SecOps tools
How we comply largely depends on the tools we use in the GRC and SecOps space. These ISVs often do not cooperate to share data; therefore, we must layer in the federated rules to determine what we can send to which ISV, what we will receive in return, and how to get the tools to work together in a “federated patchwork” to achieve compliance.
You will likely have at least one GRC tool and at least one SecOps tool. You may have multiples of both in some cases, as shown in the illustration below.
Organizational GRC and SecOps tools
In the real world, as in the illustration below, you will have the following:
- Threat and vulnerability feeds prompting you to act;
- Guidance from the ADs that map to your common controls, indicating the mandates you will need to implement;
- Mandates that tie to low-level configuration controls for protecting your systems;
- An understanding of the various roles assigned to your controls, along with the knowledge and skills required for users to implement the controls and
- Metrics and reporting for both implementation and auditing of your controls.
An overlay of AD elements across your GRC and SecOps tools
With all that compliance and security data being exchanged, you will encounter federated rules for the following:
- What data can (and should) be shared with which GRC or SecOps tools.
- How the data is structured in JSON (See GRCSchema.org).
- How do the high-level GRC controls work with the low-level SecOps controls?
- How personnel roles interact with the data and tools.
- What are the rules for reporting compliance with both the low-level and high-level controls, and how do they map together?