GOVERN 2.2 AI risk management training: requirements and evidence

GOVERN 2.2 AI risk management training: what the requirement asks

GOVERN 2.2 is an outcome in the Govern function of the NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1). It states that personnel and partners receive AI risk management training that lets them carry out their duties consistently with related policies, procedures and agreements. If you are a compliance lead, engineer or buyer asked to show that the people building, operating and overseeing AI, plus the vendors and contractors working alongside them, know their AI risk responsibilities, this subcategory is the one that answers that question. The underlying risk is simple: people who do not know what the organization's AI policies require cannot apply them, and AI harm then goes uncontrolled inside ordinary workflows. The AI RMF is voluntary, and NIST does not certify anyone against it, so there is no external badge to point to. An assessor or customer will instead ask for your own records showing what training was delivered, to whom, and what it covered.

The difficulty is rarely launching a course. It is tying training to roles, extending it to partners and proving that people understood it. A single generic module given to everyone will not match what a developer, an operator and an internal audit reviewer each need to do. Partners such as integrators, model providers and outsourced labelers sit outside your HR system, so their completion records may live with someone else. Completion itself is also weak evidence: a checkbox shows that someone clicked through, not that they can apply the rules. Before you commit budget, confirm three things with your own owners: which AI roles exist and who holds them, which contracts must require partner training, and what proof of understanding your policies accept, such as acknowledgments or short assessments tied to the role.

Who needs GOVERN 2.2 AI risk management training

GOVERN 2.2 asks that personnel and partners receive training that lets them carry out their duties consistently with AI policies, procedures and agreements. The groups below differ in what they must understand, so the scope decision for each group drives how much training is built and who must complete it. Start by listing every person and partner who touches an AI system, then assign each one to a group.

Technical builders and operators

Developers, data scientists, MLOps engineers and platform operators who build, deploy or run AI components. They need to understand the organization's AI policies, the trustworthy AI characteristics the system must meet, and the testing, logging and rollback steps their role performs. Training should be hands-on and tied to the actual pipelines and runbooks they use. Check whether each engineer with deployment rights or production access is on the roster, not only those whose job title includes AI. Confirm that every person with deploy rights is enrolled before the first release.

Oversight and assurance roles

Legal, compliance, internal audit and risk staff who review AI systems, approve use cases or test controls. They need to understand applicable AI laws, the potential negative impacts the organization has documented, and how evidence is produced so they can challenge it. Training for this group is usually shorter and focused on decisions and evidence, not model internals. Ask whether approvers of AI use cases have completed the same course as the reviewers who sign off on them.

Contractors with production access

Contractors, consultants and staff from vendors who hold accounts, credentials or change rights in environments where AI components run. They can affect system behavior even though they sit outside the employee record. The scoping decision is whether these individuals count as partners under GOVERN 2.2 and must complete the same training, or whether their agreement alone covers them. Where access is granted, require completion as a condition of that access and record it.

Third-party AI vendors and suppliers

Vendors that supply models, datasets, hosted AI services or components that the organization builds on. GOVERN 2.2 extends to partners, so contracts should state which vendor personnel must understand the organization's AI policies and how they will be trained. Ask vendors to show their training records for staff who support the account, and confirm that the agreement covers updates when vendor staff change. Do not assume that a vendor's general security training covers AI risk.

Leadership and business owners

Business owners who define AI use cases and accept the resulting risks. They need enough understanding of AI risk to recognize when a decision goes beyond their authority, and to know which policy applies to their use case. This group often gets briefings rather than full courses. Decide whether business owners are required to complete training before they sponsor a system, and document that requirement in the AI policy.

How an assessor tests GOVERN 2.2 AI risk management training

This table compares what an assessor does, what evidence they request and where training programs usually fall short for GOVERN 2.2. The AI RMF has no certification or NIST assessment procedure, so each row tests against the organization's own training commitments and the Playbook suggestions. Read it as a checklist for preparing evidence before an internal audit, customer review or independent assessment.

Assessment element	What the assessor does	Evidence requested	Where it usually fails
Test approach	Compares the training program against the AI policies, procedures and partner agreements the organization has adopted, since no NIST test procedure exists	Written policy list, training standard, and a mapping of each policy to the roles that must be trained	Training exists but is not tied to any named policy or obligation
Sampling of roles	Selects a sample of technical roles (developers, operators) and oversight roles (legal, compliance, audit) and checks each sampled person's training	Role inventory, training records per sampled person, and the role-to-course assignment	Oversight roles are never assigned training, or technical staff receive only generic content
Content alignment	Checks that course material covers the AI laws, internal AI policies and trustworthy AI characteristics the organization has adopted	Course outlines, slide or module versions, and dates showing when content was last reviewed against current policy	Content references retired policies or omits characteristics such as privacy or fairness that the organization committed to
Completion and acknowledgment	Confirms that training was completed and that personnel acknowledged their AI roles and responsibilities	Completion reports with dates, signed or recorded acknowledgments, and any exceptions with follow-up	Completion is recorded only for a launch event, with no evidence of acknowledgment or later refresh
Partner agreements	Reviews contracts and statements of work for training obligations placed on vendors, contractors and other partners	Contract clauses, partner training attestations, and a list of partners with access to AI systems	Partners with access to AI systems have no training obligation written into their agreements
Ongoing education	Looks for evidence that training continues after onboarding, such as refreshers after policy changes or new AI laws	Training calendar, change log linking policy updates to course updates, and records of periodic reviews	Training is delivered once at onboarding and never updated
Effectiveness	Checks whether the organization tests understanding or only tracks attendance, and how it acts on results	Assessment results, follow-up actions on low scores, and management review notes	Attendance is tracked, but no measure shows that staff can perform their duties under the policies
Use of the Playbook	Notes whether the organization used the Playbook suggestions as input, without treating them as a checklist	Documented decisions on which Playbook suggestions were adopted, adapted or declined, with reasons	Playbook suggestions are copied without decisions, or ignored with no record

How to implement GOVERN 2.2 training step by step

This sequence turns the GOVERN 2.2 outcome into a working training program: each AI role gets the training it needs, completion is recorded, partners are covered, and the program is refreshed whenever the policies it teaches change. Each step ends with a named output you can show an assessor.

Map AI roles from the documented role structure
Start from the roles, responsibilities and lines of communication your organization has already documented under GOVERN 2.1, and list every person and partner who touches an AI system, from developers and operators to legal, compliance and audit. Group them into technical roles, such as developers and operators, and oversight roles, such as legal, compliance and audit, because the Playbook suggests tailoring training to these two families. The output is a role-to-course matrix that names each role, its group and the policies it must follow. If no role map exists yet, build it first, since training that does not match real responsibilities is hard to defend.
Define training content for each role group
For each role group, write a curriculum tied to your own AI policies, procedures and agreements rather than generic awareness material. The Playbook suggests covering applicable AI laws, potential negative impacts, organizational AI policies and the trustworthy AI characteristics, so build each module around the parts of those topics that a given role must act on. Technical roles typically need depth on testing, documentation and incident escalation, while oversight roles need depth on approval decisions, evidence review and contractual obligations. The output is a short curriculum document per role group with learning objectives that point back to specific policy sections.
Set completion and acknowledgment rules
Decide what counts as completed training and what each person must acknowledge. Define the completion condition for each module, such as passing a short assessment, reviewing the material or signing an acknowledgment of roles and responsibilities, which the Playbook suggests. Confirm with your learning platform how it decides completion. Moodle, for example, can mark an activity complete when a learner views it, receives a grade or ticks it manually, depending on the conditions you set. The output is a written completion standard that specifies, for each role group, which condition is required.
Deliver and record training for staff and partners
Deliver the curriculum to internal staff and to partners whose work depends on your AI policies, and extend the same expectations to contracts where a partner's personnel act on your systems. Partners need a clear route to training and acknowledgment, which may be their own training if your agreements allow it, so confirm that wording in the contract. Record each completion with the person's name, role group, module version, date and acknowledgment. Confirm your platform can export these records, and confirm who in the organization can access them. The output is a completion record for every person and partner in the role matrix, with gaps listed.
Close gaps and verify coverage
Compare the completion records against the role-to-course matrix and follow up on anyone who has not completed the required modules or acknowledgment. Check that new hires, role changes and new partners are captured by the matrix, not only the people present at launch. Keep a short exception log for anyone granted a temporary waiver, with the approver and the reason. The output is a coverage report showing that every mapped role has either completed its training or has a documented exception.
Set a refresh cycle tied to policy changes
Tie the refresh cycle to changes in the policies the training teaches, rather than only to the calendar. Each time a GOVERN 1 policy, risk tolerance, AI law obligation or procedure changes, identify which curriculum modules and role groups are affected and update them. Plan for the NIST AI RMF itself to change, since NIST says AI RMF 1.0 is being revised, so track that revision and any state law that cites a specific version. Where you use a wiki or document system, version control helps show what changed, when and by whom. The output is a refresh schedule and change log that links each policy change to the training update it triggered.

Which evidence shows GOVERN 2.2 training is in place

What is a role-to-training matrix and why do assessors ask for it?

A role-to-training matrix is a table that lists each AI role in your organization and the training that role must complete before it performs its duties. Assessors use it to confirm that training is planned from roles, not assigned at random. A useful matrix names each role group, such as developers, operators, legal, compliance and audit, and maps it to the AI policies, procedures and partner agreements that role relies on. Keep it under document control in your wiki or GRC tool, with an owner and a review date. Between audits, update it whenever a role is created, split or retired, and when a new policy changes what a role must know. The matrix is maintained by your organization. An implementation partner can help draft it, but the roles and training requirements must be yours.

What should an AI training curriculum for each role group include?

An assessor checks that each role group's curriculum covers the topics the Playbook suggests for GOVERN 2.2: applicable AI laws, potential negative impacts, organizational AI policies and the trustworthy AI characteristics in AI 100-1. Technical roles such as developers and operators should go deeper into testing, failure modes and monitoring. Oversight roles such as legal, compliance and audit should focus on policy interpretation, evidence review and escalation. For each module, record which internal policy or procedure it explains and which trustworthy characteristic it addresses. That link is what turns a generic course into GOVERN 2.2 evidence. Review curricula after any material policy change or new regulation that applies to your systems. Curriculum design and content are your decisions, though training providers or an implementation partner can build or host the materials.

How do completion records show that training actually happened?

Completion records show who finished which training, on what date, and against which version of the course. An assessor will sample names from the role matrix and check that each person holds a record for every module their role requires. Records should include the learner's name or account ID, the module, the completion date and the course version. Learning management systems can produce this automatically. For example, Moodle's activity completion can mark an activity complete when a learner views it, receives a grade from it, or ticks it manually, depending on how the activity is configured. Choose the completion condition deliberately, because viewing a page is weaker evidence than passing an assessment. Export records on a schedule and keep them in a retained, access-controlled location. Confirm your chosen platform's completion options and export formats before relying on them.

What do signed role acknowledgments prove?

Signed role acknowledgments show that each person has read and accepted the AI roles and responsibilities assigned to them. The Playbook suggests having personnel acknowledge their AI roles, so assessors look for a signed or electronically accepted statement per person, dated and linked to the role description. The statement should name the responsibilities, reference the policies that apply, and say what the person must escalate. Store acknowledgments with the training record and re-collect them when a role changes. A common gap is acknowledgments that are collected once at hiring and never updated when the person moves to an oversight or technical role. Your HR or GRC process owns this step. Any e-signature or document system you use should keep an audit trail of who signed, when and which version they accepted.

What evidence covers partner and contractor AI training?

GOVERN 2.2 extends to partners, so you need evidence that external parties who touch your AI systems are trained to carry out their duties consistently with your policies and agreements. The most direct evidence is a training clause in each relevant contract, statement of work or data processing agreement. The clause should state what training the partner must complete, how quickly after onboarding, and what proof they must provide. Assessors will sample partners in scope and check for both the clause and the completion evidence. Track partner training in the same matrix as internal roles, with the agreement reference beside each entry. Keep the list current as partners are added or contracts renew. Your procurement and legal teams own the contract language, so confirm the wording with counsel rather than relying on a template alone.

What refresh records prove training keeps up with policy changes?

Refresh records show that training was updated and re-delivered after policies, laws or AI systems changed. An assessor will ask for a change log that ties each policy revision or significant system change to the training modules it affected, plus the date those modules were reissued and who completed them. Version control in your documentation platform helps here. XWiki, for example, keeps every page change with what changed, when and by whom, and lets you compare versions and roll back, which gives you a clear trail for training materials. Set a periodic review date for each curriculum even when nothing has changed, and record the review outcome. Between audits, make refresh a standing step in your policy change process so it is not forgotten. Decide the review cadence yourself based on risk and applicable law, and confirm it with your auditor.

How should evidence for GOVERN 2.2 be kept current between audits?

Keep evidence current by making each artifact a routine output of a process you already run, rather than a project before an audit. Assign an owner to the role matrix, curriculum, completion export, acknowledgment set and partner clause list, and set a review date for each. Use the same access rules across all of them, for example role-based permissions in BookStack, which can be set per shelf, book, chapter or page, so only authorized staff can edit training records. Run a quarterly sample check: pick a few roles and people, then confirm the matrix, completion record, acknowledgment and curriculum version all agree. Gaps found in that check are your remediation list. Assessors generally look for consistent, dated records over a period, so a steady routine matters more than a single large export. Confirm the evidence period and format your auditor expects before you set the cadence.

Open-source tools that produce GOVERN 2.2 training evidence

GOVERN 2.2 expects training that lets personnel and partners perform their AI risk duties, so the organization needs records that show who was trained, on what, and which version of the material they used. The three tools below cover completion tracking, version history for policies and curricula, and role-based access to training content. Each must be deployed and configured inside the client's own environment, and the organization should confirm every capability in its own setup.

Moodle completion records

Moodle is a learning management system licensed under GPL-3.0-or-later. Its activity completion feature can mark an activity complete when a learner views it, when they receive a grade, or when they tick it manually, depending on how each activity is configured. For GOVERN 2.2, this lets the organization show which technical staff, oversight roles and partner personnel finished training on AI laws, organizational AI policies and trustworthy AI characteristics. Check that each course sets the completion condition that matches the evidence you need, because a view-based condition alone does not show comprehension.

XWiki version history

XWiki is a wiki platform licensed under LGPL-2.1-or-later. It keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. For GOVERN 2.2, this supports change records for AI policies, role descriptions and training curricula, so an assessor can see which version of a policy was in force when a person was trained. Confirm how your team will require approval before a new version becomes the one staff are trained against.

BookStack role-based access

BookStack is a documentation platform licensed under MIT. User abilities come from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. For GOVERN 2.2, this supports controlled access to training material, so that oversight roles such as compliance and audit can read governance content while developers and operators see the material written for their duties. Confirm in your own setup that role assignments match your documented AI roles and that overrides are reviewed when staff change jobs.

What GOVERN 2.2 AI risk management training costs to meet

This table compares the cost components of building and running GOVERN 2.2 training, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No price figures are given because no researched cost figures are available, so use the drivers and the quote questions in the final rows to compare proposals.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Course development or licensing	One-time build, recurring if licensed per seat	Number of distinct role curricula (technical versus oversight), volume of content to produce, and whether a commercial library is licensed per learner	Reuse one base module on AI laws, impacts and trustworthy characteristics, then add role-specific modules. Self-hosted open-source learning tools such as Moodle (GPL-3.0-or-later) can remove per-seat platform license spend, though content production stays an internal or contracted cost
Engineering or platform time to configure the learning system	One-time setup, recurring for upgrades and integrations	Single sign-on and directory integration, course completion reporting, and how many systems need to feed training records	Use the native activity completion settings to record completion, and confirm integration needs before scoping. Ask the implementation partner to fix the scope in writing before work begins
Instructor or content time	Recurring	Number of cohorts, frequency of refresh, and how many subject matter experts must review each module	Schedule refreshes on a fixed review cycle tied to the policy review process rather than ad hoc updates, and record reviewer sign-off in a version-controlled wiki such as XWiki
Partner onboarding	One-time per partner, recurring as partners change	Number of third-party partners who need training under their agreements, and how many access tiers they require	Limit partner training to the modules their agreements require, and use role-based access in a platform such as BookStack to restrict content to each group
Evidence upkeep	Recurring	How many acknowledgments, completion records and version histories must be kept, and how long the organization retains them	Automate completion records and staff acknowledgment of AI roles and responsibilities, and keep the training record in the same system that holds the policy version it refers to
Policy change and curriculum rework	Recurring, triggered by events	Rate of change in applicable AI laws, internal AI policies and the NIST AI RMF revision now in progress	Track legal and policy changes against a named owner, and update only the affected modules instead of rebuilding the full curriculum
External review of curriculum	Recurring if scheduled, one-time for an initial review	Whether an outside legal, compliance or subject matter reviewer checks the content, and how many reviews a year are required	Ask for review scope in writing and limit it to legal accuracy and role fit. Note that a reviewer's comments do not make the training an assessed or certified control
Quote questions to ask	Applies to every row	Which components are one-time, which recur, which are licensed per learner, and which depend on the number of roles and partners	Ask for line items by component, the assumptions behind each, the change-handling process, and whether any platform licenses are included or excluded

Who owns GOVERN 2.2 training: your team, a partner and the auditor

Your organization owns GOVERN 2.2 because the outcome describes people in your company being trained to carry out duties consistently with your own policies, procedures and agreements. No partner or assessor can decide what your staff must know about your AI systems. Your team sets the policy that requires training, defines each AI role and decides which knowledge each role needs.

Policy and role definitions: Name the AI roles that exist in your organization, such as developers, operators, legal, compliance and audit, and state which obligations attach to each.
Curriculum decisions: Decide the topics for each role, including applicable AI laws, potential negative impacts, internal AI policies and trustworthy AI characteristics.
Acknowledgments: Require personnel and relevant partners to acknowledge their AI roles and responsibilities, and keep those signed records under your control.
Refresh cycle: Decide how often training is repeated and when it is triggered by policy changes or new systems.
Partner oversight: Approve any outsourced content before it is used.

Before you engage anyone, confirm that you can name the owner of each role-to-course decision and who signs off on changes.

Common gaps in AI risk training and how to close them

GOVERN 2.2 asks that personnel and partners receive training that lets them act consistently with AI policies, procedures and agreements. The gaps below are the ones that most often leave that outcome unmet on paper, even when a course exists. Each card names the gap and the concrete fix an assessor would expect to see.

One generic course for every role

A single awareness module given to developers, operators, legal and audit teams ignores that each group carries different duties. The NIST AI RMF Playbook suggests tailoring training to technical roles, such as developers and operators, and to oversight roles, such as legal, compliance and audit. Build at least two tracks: one covering model testing, data handling and incident escalation for technical staff, and one covering applicable AI laws, impact review and policy exceptions for oversight staff. Check that each track names the policies and procedures it teaches.

Partners left out of training

GOVERN 2.2 covers partners as well as personnel, so contractors who build, label data for, or operate AI components fall inside the outcome. Many programs train employees and then assume vendors follow the same rules. Require contracted parties to complete the training track that matches their work, or accept equivalent training that you have reviewed. Record the agreement terms that reference AI policies, so a partner's duties trace back to a written obligation.

Completion without understanding

A learner who opens a page or clicks through slides is not the same as one who can apply the policy. Moodle's activity completion can mark an activity complete when a learner views it, receives a grade, or ticks it manually, so the completion condition itself determines what the record proves. Set quizzes or practical tasks as the completion condition for role-critical modules, and require a signed or recorded acknowledgment of AI roles and responsibilities, which the Playbook also suggests.

Curriculum not updated after policy changes

Training that describes last year's AI policy or a superseded version of a standard will not support consistent duties. NIST notes that the Playbook's last content update is dated August 2023 and that AIRC plans updates after AI RMF 1.0 is revised, so your own internal policies and legal references need a review trigger. Assign an owner to each module, tie it to the policy change log, and set a review date after every material change to an AI policy, a related agreement or an applicable law.

No link between training and role definitions

When training content and role documents are maintained separately, people can complete a course for a role they no longer hold, or hold a role no course covers. Map each documented AI role to a required training track, and keep that map in the same controlled documentation set as the role definitions. In XWiki, page version history records what changed, when and by whom, which gives an assessor a trail between a role revision and the training that followed it.

No evidence of version trained

Completion records that show a name and a date do not show which policy text or course version the person saw. Store the course version and the policy version alongside each completion record, and retain both. In BookStack, role-based permissions can limit who may edit training pages and who may view them, so the people who approve content are separate from the people who publish it. Keep the export of completion records as evidence that matches the version each person actually took.

Questions buyers ask about GOVERN 2.2 training

How much effort does GOVERN 2.2 training take?

The effort depends on how many people need training, how many distinct roles they hold and how much AI your organization builds, buys or operates. GOVERN 2.2 asks that personnel and partners receive training that lets them perform their duties consistently with related policies, procedures and agreements, so the work starts with a list of roles and the policies each role must follow. Effort rises with the number of AI systems in scope, the number of roles that touch them, and how often the policies change. Ask any provider to break its estimate into role analysis, course design, delivery, acknowledgment tracking and refresh cycles, and to state which of those it expects your staff to perform.

How long does it take to put GOVERN 2.2 training in place?

The timeline is driven by how quickly your policies and AI role definitions are settled, because training cannot teach a policy that is still being written. Organizations that already have documented AI roles, an AI policy and an inventory of AI systems can move faster than those starting from nothing. Other drivers include approval cycles for course content, the number of audiences that need separate material, and whether training is delivered through an existing learning platform. The NIST AI RMF is voluntary and has no certification, so no external deadline sets the pace unless a contract or regulator does. Ask for a schedule that ties each phase to a named dependency.

What does the work need from our own staff?

Your staff must own the decisions that a training program cannot make for you. These include defining which AI roles exist, deciding which policies apply to each role, naming the people who approve course content and confirming that the material matches how your organization actually uses AI. Legal, compliance and audit staff are typically needed to confirm which AI laws apply, while engineering leads confirm how developers and operators work with AI systems. Expect ongoing time from named owners for reviews and for answering questions raised by learners. Ask any provider which decisions it expects your team to make and which tasks it will carry out.

Can we run GOVERN 2.2 training in-house?

Yes, an organization can design and deliver GOVERN 2.2 training with its own staff, and the NIST AI RMF Playbook offers suggested actions that can guide the content. In-house delivery makes sense when a team already has instructional design skills, a learning platform and people who understand both AI systems and the relevant policies. Outside help becomes more useful when the team lacks time, when roles are unclear, or when training must be tied to evidence for an assessment. Whichever path you choose, the organization owns the training and its records. Ask whether the training can be maintained by your team after handover.

Do our AI partners and vendors need training, and how is it delivered?

GOVERN 2.2 covers personnel and partners, so contractors, service providers and other third parties who work with your AI systems should be trained in the policies and procedures that bind them. The practical route is to set training requirements in contracts or onboarding terms, then record completion and acknowledgment. Learning platforms can track completion for each learner in a course, and wiki or documentation systems can keep version history of the policies that partners must read. Confirm with each partner how it will evidence training, because your records will be the ones an assessor asks to see.

Can the NIST AI RMF be certified, including GOVERN 2.2?

No. The NIST AI RMF has no certification, accreditation or conformity assessment program, and NIST does not validate or endorse any organization's use of the framework. Because of this, no one can issue a certificate for GOVERN 2.2 training. What you can do is show evidence that the training happened, such as course records, role definitions and signed acknowledgments, and let a reader judge it. If a customer or contract asks for certification, ask them which other standard they mean, since frameworks such as ISO/IEC 42001 do have a third-party certification route. Independent auditors and certification bodies, not implementation partners, issue any reports or certificates.

What evidence will an assessor ask to see for GOVERN 2.2?

An assessor will usually look for proof that training was defined, delivered and reached the right people. Useful evidence includes a list of AI roles, the training content for each role, completion records and signed role acknowledgments, plus a record of when content was last reviewed. Each piece should show a date and an owner. Records kept in a learning platform, such as completion tracking, combined with versioned policy pages, make this easier to produce. Confirm with your auditor or customer which format they accept before you build the program.

How DeployOpen works on this

DeployOpen helps organizations build the training evidence that shows personnel and partners can carry out AI risk duties consistently with their policies, procedures and agreements. The organization owns its training program and its outcomes, while DeployOpen prepares the learning systems, records and documentation that show it operating, and an independent assessor decides what is adequate.

How we scope

Each engagement starts with a written scope that names the roles, audiences and AI systems covered by GOVERN 2.2 training.
We agree which personnel groups are technical roles and which are oversight roles, such as legal, compliance and audit.
Scope documents list the training topics, acknowledgment steps and records the organization expects to keep.

How we build

We configure the self-hosted learning platform inside your environment, with courses tailored to developers and operators versus oversight staff.
Course content covers applicable AI laws, potential negative impacts, internal AI policies and trustworthy AI characteristics, drawn from your own policies.
Completion tracking and role-based access are set up so each learner's records reflect their assigned AI responsibilities.

How we hand over

Handover includes training materials, role mappings, completion settings and a document describing how the training records are produced.
Version history for training pages and policy documents is configured, so changes can be traced to a date and an author.
Your staff receive instructions for running the platform, with the evidence each assessor is likely to request clearly listed.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, based on the written scope.
Training content is reviewed when NIST revises the AI RMF or when your AI laws or internal policies change.
Questions about whether the training meets your assessor's expectations should go to the assessor, and we confirm the evidence before the assessment begins.

GOVERN 2.2 AI risk management training