How often should AI governance training be refreshed?

Annually is the baseline cadence for the general workforce track. The CISO, CRO, compliance, and platform engineering tracks need event-driven refreshers whenever a new regulation enters scope, a new model provider is approved, a major policy version is released, or a material incident occurs. The training records need to capture both the scheduled and the event-driven completions, with version references to the policy and curriculum each individual was trained on. The auditor will sample decisions from time windows that may pre-date the most recent refresh; the institution needs to show the training that was in effect at the time of each sampled decision.

Who should deliver AI governance training?

The internal program is delivered by the AI governance lead working with HR and Learning and Development. For the CISO, CRO, and compliance track, external credentialing through the IAPP AIGP or equivalent is increasingly expected. For the platform engineering track, the training is most effective when delivered by the engineers who operate the runtime enforcement layer, because the content is technical and changes as the architecture evolves. The general workforce track is typically delivered through the institution's existing LMS with scenario-based content.

Does the EU AI Act require specific training?

Article 4 of the EU AI Act addresses AI literacy obligations for providers and deployers of AI systems. The article requires that staff and other persons dealing with the operation and use of AI systems on behalf of the provider or deployer have a sufficient level of AI literacy, taking into account their technical knowledge, experience, education, training, and context of use. The article does not prescribe a specific curriculum. It establishes the legal expectation that the institution operates an AI literacy program. The role-specific training tracks described above are how institutions discharge that obligation in practice.

How does AI governance training interact with the general cybersecurity training program?

The two programs are separate but coordinated. The cybersecurity training covers phishing, password hygiene, data classification at the document level, incident reporting, and other established topics. The AI governance training covers the AI-specific extensions: prompt content rules, sanctioned tool lists, model interaction etiquette, exception procedures. The coordination point is the AI usage policy itself, which extends the data governance and data loss prevention policies the cybersecurity program already covers. The general workforce track can be delivered as a module of the cybersecurity program in smaller organizations and as a separate program in regulated enterprises.

What evidence should the institution retain from the training program?

The institution retains the curriculum versions, the policy versions each curriculum was tied to, the individual completion records (with timestamps and policy version references), the competency evaluation results, and the records of exception and escalation drills. The retention period mirrors the per-decision audit retention. If the per-decision record is retained for seven years, the training records that reference the same policy version are retained for at least the same period. The training records are part of the same evidence package the institution produces under regulator request.

AI Governance Training: What to Teach Which Role Inside the Enterprise

Enterprise training programs default to a single all-hands curriculum: a sixty-minute video, an attestation checkbox, and a yearly refresh. AI governance training delivered this way produces a workforce that passed the quiz and a CISO who cannot point at a population of users with the operational literacy to handle a regulator's question. Regulators and auditors increasingly ask the institution to demonstrate role-specific training, with completion records, content versions, and competency evaluations that map to the responsibilities each role actually holds. The Cloud Radix research found that 78% of employees use unauthorized AI tools at work and 77% admit to pasting sensitive business data into unsanctioned models. The training program is the institution's first defense against that pattern, and the single-track approach does not produce the outcomes the regulators are asking about.

I want to walk through the role-specific training tracks an enterprise AI governance program needs, what each track covers, and how the training program ties into the runtime evidence the regulator examines.

The role-specific training tracks

The training program for a regulated enterprise needs five distinct tracks. Each track has its own curriculum, its own completion record, and its own competency evaluation.

General workforce track

The general workforce track covers the AI usage policy in operational terms. What employees may and may not paste into a model. Which sanctioned tools are available and which third-party tools are blocked. What the institution does with prompts and responses. How to report a suspected exposure. The track is short, scenario-based, and refreshed when the policy changes. The output is a workforce that has been informed of the rules and recorded as having received the training.

Executive and board track

The executive and board track covers the regulatory landscape, the institution's AI inventory, the residual risk position, and the disclosure obligations. The track does not teach the executives how to use models. It teaches them what to ask the CRO and CISO and how to read the AI governance dashboard. Under Fannie Mae LL-2026-04, AI governance is a named board-level accountability for mortgage lenders. The board needs the literacy to discharge it.

CISO, CRO, and compliance track

The CISO, CRO, and compliance track covers the regulatory texts directly: EU AI Act articles 12, 19, 26, 27, and 99. NIST AI RMF. ISO/IEC 42001. Sector-specific mandates (Fannie Mae, Freddie Mac Section 1302.8, Texas TRAIGA, California AI Transparency Act). The track covers the structure of the per-decision audit record, the disclosure procedure, and the exception workflow. The track produces the credential the institution lists when a customer or regulator asks who is qualified to discharge the AI governance obligation. The IAPP AIGP credential is increasingly the baseline external qualification expected for this track.

Platform engineering and AI engineering track

The platform engineering and AI engineering track covers the technical architecture of policy enforcement at the AI request boundary. How identity context propagates from the user through the application to the request layer. How the proxy classifies prompts and applies policy. What the per-decision audit record contains and how it is signed. How to integrate the runtime layer into new AI deployments. The track produces the engineers who can implement the controls the regulators ask for.

Internal audit and risk track

The internal audit and risk track covers the sampling and testing methodology for AI governance audits. How to select decisions for sampling. What evidence to request for each sample. How to test whether the per-decision records reconstruct the decision. The track produces the second-line-of-defense capability that tests the first line's controls. Without trained internal auditors, the institution discovers control gaps during the external audit, which is the most expensive moment to discover them.

What each track has to produce

Beyond the content, each track has to produce three artifacts the auditor will sample.

Completion records by role and policy version

The training records map each individual to the version of the policy they were trained on. When the policy changes, the training records show who has been re-trained against the new version. The auditor samples decisions from a specific time window and asks whether the user who made or was involved in the decision had been trained on the policy in effect at that time. Without policy-versioned completion records, the institution cannot answer the question.

Competency evaluations, not attestation checkboxes

The completion record alone does not establish competency. Regulators increasingly expect the institution to evaluate the competency of the population, not just record attendance. Scenario-based assessments, role-specific case studies, and recurring evaluations are the operational pattern that holds up under scrutiny. The competency evaluation is the artifact that distinguishes a defensible training program from a quiz.

Exception and escalation drills

The training program needs to include exception and escalation drills, especially for the CISO, CRO, and platform engineering tracks. The drills exercise the procedure the institution has documented for an AI-related incident. Without rehearsal, the procedure exists on paper and fails when an actual incident occurs.

How the training program ties into runtime evidence

The training program produces the policy literacy. The runtime layer produces the per-decision records. The two artifacts are linked because the per-decision record references the policy version in effect at the time of the decision, and the training records show which users had been trained on that policy version.

When a regulator samples a decision and asks who was responsible, the institution produces the per-decision record (from the runtime layer) and the user's training record (from the training program). Together, the two records support the institution's case that the decision was made under a known policy by a user who had been trained on that policy. Without the linkage, the institution has either a record of a decision without the policy literacy behind it, or a record of a trained user without evidence of what they did.

DeepInspect

This is the runtime evidence layer DeepInspect provides for the institution's training program to link against. DeepInspect sits at the AI request boundary as a stateless proxy between the application and any LLM. Every request is evaluated against per-route and per-role policies. Every decision produces a per-decision audit record containing identity, role, policy version, data classification, decision outcome, and timestamp. The record is signed and committed before the application receives the model's response.

For the training program, the proxy provides the runtime artifact that links to the training records. The policy version field in the per-decision record points at the policy the user was trained on. The auditor samples both records together.