The Compliance Template and the Worker

A compliance template is a particular kind of document. It exists because an organization needs to demonstrate, to a regulator or a board or an insurer or itself, that it has thought about a category of risk. The template is the artifact of thinking. The thinking may or may not have occurred. The template is the evidence that it did.

AI use policies, as they are currently produced by the consulting firms and law firms and HR-focused publishers that sell them, are compliance templates. They are written to be adopted, customized lightly, and attached to internal communications about AI deployment. The customization is mostly cosmetic. The substantive provisions — what counts as appropriate use, what reporting requirements exist for AI-related incidents, what human-oversight mechanisms apply, what training is required — are similar enough across templates that you could swap the headers and most readers would not notice.

This is not a criticism of the firms producing the templates. They are producing what their customers buy. The customers are executives and HR directors who need to attach a document to a board presentation or a workforce communication. The document needs to look rigorous. It does not need to do anything specific, because no one — not the regulator, not the board, not the insurer — has yet developed the operational criteria that would tell us whether an AI use policy was working in practice. The template's job is to exist. It does the job.

What the template does not do, and what no one in the supply chain is asking it to do, is answer the question that the worker affected by the AI deployment is asking. The worker, in the framework the template constructs, is the object of the policy, not a party to it.

This piece is about what that mismatch looks like in practice, and what would have to change for it not to be the default.

The frame that the templates produce

Open an AI use policy template — there are many available, several free, several from major consulting firms — and read it. The document has a recognizable shape.

The introduction sets the scope: this policy applies to all employees and contractors who use AI tools in the course of their work for the organization. The body of the policy enumerates expectations: AI tools should be used in accordance with ethical principles; outputs should be reviewed by qualified humans before being relied upon; certain categories of use are prohibited (high-risk decisions affecting employment, health, legal status of individuals); incidents should be reported to a designated officer; training will be provided. There is a section on data privacy. There is a section on intellectual property. There is a section on disclosure to clients or counterparties. There is a section on enforcement: violations of the policy may result in discipline up to and including termination.

The frame, throughout, is that the AI tool is a thing the worker uses, and the policy is the set of rules the worker must follow when using it. The worker is the user. The tool is the object. The policy governs the user's relationship to the object.

What is missing from this frame is the prior question: how did the tool come to be in the worker's hands, what considerations went into the deployment decision, and what avenues exist for the worker to register a substantive objection to the deployment or its terms?

These questions are absent from the template because the template assumes the deployment has already happened. The template comes into force after the executive has decided. The policy's job is to govern the workforce's response to a fait accompli, not to govern the decision itself.

This is the structural shape of the AI governance literature as it currently exists. The locus of decision-making is upstream of the policy, and the policy regulates the downstream. The worker is downstream. The worker does not appear in the upstream proceedings.

Why this is not "just procurement"

A possible objection is that this is no different from how organizations have always procured tools. The IT department decides which laptop you get, which email system, which collaboration platform. You do not consult on these decisions. You use what is provided. AI tools are just another category of provisioned tooling. The compliance template treats them like provisioned tooling. The frame is consistent.

This objection holds for some AI tools. A spell-checker built into a word processor is provisioned tooling. A meeting-transcription service is provisioned tooling. The compliance frame is adequate for these.

The objection fails for AI tools that change the substance of the work rather than its surface. An AI tool that evaluates job applicants does not provision a capability; it replaces a function the worker (the hiring manager, the recruiter) was previously performing with judgment that the worker is now expected to defer to or override. An AI tool that drafts legal documents does not provision a capability; it substitutes for a function the worker (the lawyer, the paralegal) was previously performing and is now expected to verify. An AI tool that diagnoses patients does not provision; it substitutes. An AI tool that grades student work does not provision; it substitutes.

The substitution category of AI tools is qualitatively different from the provisioning category. The worker's stake in the deployment is different. Their expertise is being either delegated to or displaced by the tool. The legitimacy of either outcome depends on whether the worker's expertise was actually engaged in the decision about what the tool would do.

The compliance template does not distinguish between the two categories. It treats all AI tools as provisioning. It governs the use of the substitution-category tools using the same frame as the provisioning-category tools. This is the structural mismatch.

What the worker is asking that the policy does not answer

A worker about to use an AI tool that substitutes for part of their expertise has several questions that the compliance template does not address.

What is the tool's evidence base? An AI tool deployed to make or shape professional judgments has been trained, evaluated, and validated by some process. The compliance template does not require the deploying organization to share the evidence base with the workers being asked to use the tool. The worker is in the position of using a tool whose reliability they cannot evaluate from the inside.

What is the comparison condition? When the tool's deployment is justified, the justification typically invokes some performance metric — speed, accuracy, consistency, cost. The performance metric is typically a comparison against some baseline. The baseline is typically not disclosed. The worker is in the position of having their work compared against a counterfactual they cannot examine.

What happens when I disagree with the tool? The compliance template includes a section on human oversight. The section typically says that qualified humans should review AI outputs before reliance. The section does not specify what happens when the qualified human (the worker) disagrees with the AI output. Does the worker's judgment override the tool? Are the worker's overrides recorded and tracked? Do patterns of override count against the worker in performance evaluation? The template does not say. In practice, the answer is often that overrides are tracked and used to adjust the tool, but also to evaluate the worker.

What is my exposure if the tool is wrong? The compliance template includes a section on incident reporting. The section assumes incidents are deviations from expected operation. It does not address the case where the tool's expected operation is itself the problem — where the worker uses the tool as instructed, the tool produces a wrong output, the worker relies on the output, harm results. Where does the liability sit? With the worker, who used the tool? With the organization, which deployed it? With the vendor, who built it? The template does not say. In practice, the liability is allocated by contract, and the worker is typically not a party to the contract.

What are the second-order effects on my skill? An AI tool that performs part of a worker's expert function affects the worker's own expertise over time. Cognitive offloading is real. Deskilling is real. The empirical literature on these effects is mixed and incomplete, but the direction of the effect is not seriously contested. The compliance template does not address the second-order effects. It assumes the worker's expertise is static. It is not.

These questions are not exotic. They are the questions any practicing professional would ask about a tool being deployed in their domain. The fact that the compliance template does not address them is not a defect of any individual template. It is a property of the genre.

What it would look like to address them

This is the part of the piece where the right move would be to offer a worked alternative — a worker-facing AI policy framework that addresses the gaps the compliance template leaves. We are not going to do that here, because we do not have one to offer that has been tested in practice. What we can do is name the components such a framework would have to include.

It would have to include a deployment-justification document, accessible to all workers affected by an AI deployment, that articulates the evidence base, the comparison condition, and the expected effects on the work and the workers. The document should be substantive enough that workers can evaluate the justification on its merits.

It would have to include a consultation process that occurs before deployment rather than after. The consultation should engage the workers' expertise on the question of whether the AI tool is appropriate for the use case, what its likely failure modes are, and how it should be integrated into existing workflows. The consultation should produce a record that travels with the deployment decision.

It would have to include an override protocol that is symmetric. The tool's overrides of the worker should be logged. The worker's overrides of the tool should be logged. Both should be reviewed at the same cadence. Patterns of disagreement should trigger investigation rather than being used as evaluation criteria against the worker.

It would have to include a liability allocation that is transparent to the worker. The worker should know, before using the tool, where the legal and professional risk sits. If the answer is "with you," the worker should have the standing to refuse the tool without the refusal being a termination event.

It would have to include a second-order-effects monitoring mechanism. The organization should track whether the AI tool's deployment is changing the workforce's underlying expertise, and the workforce should have access to the tracking data.

None of these components is novel. They exist in various forms in regulated industries (clinical decision-support tools in medicine, model risk management in banking, FAA-certified avionics in aviation). The components have been worked out for high-stakes deployments. The compliance-template AI governance literature has not absorbed them, because the literature serves a different purpose: low-friction deployment of AI across a wide range of organizational uses, with documentation sufficient to deflect liability and demonstrate intent.

The gap between low-friction deployment and worker-protective governance is not a technical gap. It is an interest-alignment gap. The literature serves the deploying entity. A different literature would have to serve the worker. That literature, in coherent form, does not yet exist.

Where it might come from

A different literature could come from several places.

Unions producing model AI-deployment provisions that travel into contract negotiations. The Writers Guild's 2023 contract is an example of this in a narrow sector. The work is replicable, but only in workplaces with bargaining structures.

Regulators producing sector-specific guidance that exceeds the compliance template's minimums. The EEOC's AI guidance is an example. The FDA's AI/ML regulatory framework for medical devices is an example. Both are partial; both move the floor.

Professional associations producing standards that members are expected to uphold, including standards on what tools members can and cannot use. The American Medical Association has done some of this. The American Bar Association has done some of this. The work is uneven.

Worker-led documentation efforts — journalism, academic research, organizing campaigns — that surface the operational reality of AI deployment in ways the compliance template cannot. This is currently the most active site of activity, and it is producing the strongest material. It is also the least well-funded.

Internal advocates within deploying organizations who push for the consultation processes and the override protocols and the deployment-justification documents to be real rather than nominal. This work happens. It is not visible from the outside. It depends on individual judgment and individual courage and is not a substitute for structural change.

This publication is downstream of all of these. The Foragentis editorial work is intended to make the gap visible — to give workers and organizations a vocabulary for the conversation the compliance template forecloses. Vocabulary is not enough. It is a precondition.

Foragentis works with organizations that want to take the consultation process seriously — to design AI deployment in conversation with the workers affected by it, rather than as a fait accompli with a policy attached. If your organization is at the deployment-decision stage and wants the conversation to be substantive, the 90-day discovery engagement is built for this. The first step is naming what the deployment is supposed to do, in language the affected workers would recognize.