Compliance programs overview
A compliance program is a complete, ready-to-run program that someone else built and keeps current. You install it, map it to your own departments, approve it, and then audit it.
It contains four things:
- Policies you adopt, which become controlled documents in your instance and go through your normal approval and signature flow.
- Enablement differentiated by role, because the depth a shop-floor worker needs is not the depth a person holding oversight needs.
- Assessments that produce competence evidence per person.
- Assignment rules that put each person on the right path, expressed against the program's roles rather than against your org chart.
It is not a course library. The unit of value is a defensible program, not content.
Who publishes a program
Programs come from publishers: consultancies, law firms and certification bodies whose profession is knowing what a regulation actually requires. They author the program and, more importantly, keep it correct as the law changes.
That currency is the point. A compliance handbook decays silently. The EU AI Act proved it inside a single year: an organisation that bought a governance handbook in late 2025 was told Article 4 required it to ensure a sufficient level of AI literacy, and by June 2026 that wording had been replaced and the high-risk deadline had moved sixteen months. The document did not change, and its owner had no way to know which pages were now wrong.
A program does not have that problem, because every item in it records the article it rests on and the date that reading was verified. When the law moves, the publisher issues a release and the affected content is identified mechanically.
If you are a publisher rather than a company installing a program, see Authoring and publishing.
What installing one changes
Installing a program creates real controlled documents, real training versions and real assignment rules in your instance. From that moment they behave exactly like content you wrote yourself. They are versioned, approved, signed, audited and immutable once evidence references them.
There is no separate program area with its own rules. That is deliberate.
Where accountability stays
The publisher proposes. Your quality function decides.
Nothing a program brings is published in your name until someone in your organisation approves it, and that approver cannot be the person who authored it. Installed content lands in your review queue like any other draft.
This matters for more than tidiness. An auditor asking who is responsible for a policy needs the answer to be a person in your organisation, not a vendor. Responsibility for how you use AI, or how you train your people, cannot be subcontracted. The approval trail is what shows you did not try to.
What stays yours
- The evidence. Records of who completed what belong to you and never leave your instance.
- The decision. You choose which roles map to which parts of your organisation, and you see exactly who would be assigned what before you commit.
- The final say on every revision. A publisher's release is a proposal, and it waits in your review queue until someone approves it.