Controls

Trustible Controls are the building blocks behind every framework readiness score in the platform. A control is a normative statement describing an action, a piece of documentation, or a process an organization should have in place when building, deploying, or governing AI systems. Controls exist so that a single piece of work can satisfy requirements across multiple regulations and standards at once, rather than requiring separate effort for each one.

This visual shows how a single control, such as documenting human oversight mechanisms, maps simultaneously to the EU AI Act, NIST AI RMF, ISO 42001, and Colorado SB 26-189. Completing that one control updates the compliance posture for every framework it touches.

Why One Control Can Satisfy Many Requirements

Many regulations and standards ask organizations to do fundamentally the same thing, just described in different language. Trustible normalizes these overlapping requirements into a single control. When that control is satisfied, the platform automatically reflects it as satisfied across every framework, article, or clause it has been mapped to. This means governance teams document their work once and see it credited everywhere it applies, instead of manually tracking the same requirement across a dozen different checklists.

The Six Control Types

Rather than organizing controls by the regulation they originate from, Trustible groups them by the type of governance work involved. This mirrors how teams actually operate day to day.

Organization-wide control:

• Policy controls define what an organization's AI governance policies should cover. These are satisfied when a policy document is linked and Trustible's analysis confirms it addresses the relevant guiding questions.

Inventory-level controls (attached to individual AI systems, and varying based on risk classification, assigned frameworks, and designations):

• Use case documentation controls ensure that critical information about an AI system, such as its purpose or human oversight process, is properly recorded. These are satisfied by completing the corresponding documentation fields on the use case.
• Model documentation controls cover technical detail that belongs in a model card. These are satisfied by completing the relevant model card fields.
• Model evaluation controls cover the specific tests, benchmarks, or assessments run on a model. These are satisfied by documenting and uploading test results and evaluation reports.
• Transparency and disclosure controls cover how an organization communicates about its AI systems to users, regulators, and the public. These are satisfied by uploading evidence of the disclosure mechanism.
• Workflow controls cover recurring processes, assessments, or event-triggered activities. These are satisfied by completing a defined workflow in Trustible that documents the process was carried out.

Model evaluation and workflow controls are noted as areas where the ability to satisfy controls directly within Trustible is planned as future functionality.

The Five Parts of a Control

Once a framework is added to a use case, its relevant controls attach to that use case automatically. Each control is made up of up to five components, which together provide both the detail needed for compliance work and a rollup to the broader governance picture.

1. Control statement: A plain-language description of the outcome the control requires.
2. Guidance: Practical direction on what a strong implementation of the control looks like.
3. Guiding questions: The specific questions used to assess whether the control has been met.
4. Framework articles: The exact regulatory or standard articles the control satisfies.
5. Suggested evidence: The artifacts that demonstrate the control is genuinely in place.

This structure means that when someone asks which requirements a use case or organization has met, the answer already exists as a record. There is no need to reassemble evidence from scratch.

Example: Use Case Documentation Controls

Documentation controls at the use case level map directly to the documentation fields already present in a use case record. Examples include:

• The organization documenting the justification for a selected AI model, including why it was chosen over alternatives and its expected performance.
• The organization documenting human oversight mechanisms for an AI use case, including roles, intervention protocols, and escalation procedures.

Every control displayed on a use case shows the specific evidence behind it and the exact framework article it maps to. This makes readiness reviews a matter of reading an existing record rather than compiling one on demand.