Is Your AI Policy a Liability?

Shadow AI thrives because the speed of tool adoption outpaces the speed of corporate governance. Employees do not wait for a PDF to be uploaded to a shared drive before they start using LLMs to summarise client notes or draft code. The mechanism is simple: the immediate productivity gain of the tool is certain, while the risk of a policy breach is abstract. This creates a gap where the actual operational behaviour of the company is entirely decoupled from its documented intent.

Why a lack of documentation creates systemic risk

Written rules are the only way to prevent decentralised decision-making. Without them, employees make individual judgements on what data is too sensitive to upload and which outputs require verification. This ensures that standards vary by team and that errors are only discovered after the damage is done.

According to hcamag.com, many organisations have staff using AI daily without any written rules covering approved platforms or permitted data inputs. This is a liability. When a staff member pastes commercially sensitive information or intellectual property into a public AI system, the company has effectively lost control of that asset.

How existing law handles AI harm

Existing legal frameworks already cover the output of automated systems. You do not need a specific AI law to be held liable for AI errors.

The UK Jurisdiction Taskforce reports that English common law is flexible enough to address AI-related harm by analogy. If a professional uses AI to provide a service, the duty of care remains with the human. The tool is irrelevant to the legal obligation.

Liability generally follows two paths:

Contractual: Risk is allocated via warranties and indemnities. The UK Jurisdiction Taskforce notes that contract is likely the primary route for allocating AI liability.
Tort (Negligence): Where no contract exists, negligence provides the framework. If a professional fails to exercise oversight over an AI output, they may be found negligent.

The risk of the a-posteriori policy

Writing a policy after an incident occurs is an admission of negligence. If you cannot produce a record of who approved a tool or how outputs were verified, you cannot prove you met your standard of care.

The professional consequences are already visible. Lawtelligence reports that the High Court has issued wasted costs judgments after barristers submitted documents containing fake AI-generated case citations. These cases prove that "sign-off by silence" (where a junior uses a tool and nobody objects) provides no defensible record when a regulator or judge asks who authorised the process.

Necessary elements for an operational AI policy

Operational constraints must replace high-level ethics. A policy must translate principles into a workflow that a staff member can follow during a normal working day.

To move from a liability to an asset, your policy must define these five elements:

Approved Tool Registry: A list of specific platforms that have passed security and data privacy reviews.
Data Input Constraints: Explicit rules on what cannot be uploaded, such as personal data or non-public source code.
Mandatory Checkpoints: The exact point in a workflow where a named human must verify the AI output against an authoritative source.
Transparency Triggers: Rules for when a client or stakeholder must be informed that AI was used to generate a deliverable.
Incident Escalation: A clear path for reporting "hallucinations" or suspected data leaks without fear of retribution.

Guardrails for AI use cases based on risk

Different tasks require different levels of scrutiny. You cannot apply the same level of oversight to a tool that drafts internal emails as you do to one that makes decisions about people.

The following categories define how to set guardrails based on the risk profile of the task:

Low Risk: Internal Administrative Support

You can use AI for examples such as summarising a meeting transcript or drafting a first-pass email.
A basic acceptable use policy provides control through human review for tone and accuracy.

Medium Risk: Client-Facing Deliverables

You can use the tool for drafting a report or preparing a commercial proposal.
Control involves mandatory senior sign-off and the verification of all factual claims against source data.

High Risk: Regulatory or Legal Work

Examples include legal research, financial forecasting, or medical triage.
Control is maintained through double-blind verification, explicit disclosure to the client and a rigorous audit trail.

Critical Risk: Automated Decision Making

Examples of AI-led recruitment, credit scoring, or performance management.
You can exercise control through a Data Protection Impact Assessment (DPIA), fairness audits and mandatory human override.

Prohibited: Unvetted Public Systems for Sensitive Data

An example is pasting privileged client documents into a consumer-grade LLM.
Control consists of hard technical blocks and disciplinary action for breach.

The operational fragility of AI dependency

Over-reliance on AI creates a talent vacuum and an operational single point of failure. If you automate the tasks usually performed by junior staff, you destroy the pipeline for future senior leaders who develop judgement by doing that early work.

As reported by hcamag.com, businesses face a continuity risk when they automate without retaining the human capability to perform the same function. If a vendor changes its pricing, removes a feature, or suffers a prolonged outage, a company that has outsourced its core intelligence to a third-party model becomes fragile.

Closing the enforcement gap between PDF and production

Static documents do not stop models from leaking data. True governance requires moving from a PDF in a shared drive to runtime controls.

Trussed.ai reports that many companies have policies that are ignored in practice, noting that a significant percentage of employees admit to using AI tools their employer never approved. This gap exists because policies are often written as aspirational principles rather than operational rules.

Real enforcement looks like:

Technical Guardrails: Using AI-specific Data Loss Prevention (DLP) tools to block the upload of PII or sensitive code.
Access Controls: Restricting high-risk models to a small group of vetted users.
Audit Logs: Maintaining a record of prompts and outputs for high-stakes decisions to ensure explainability.
Continuous Testing: Running bias audits on production systems to ensure they have not drifted from the original fairness criteria.
Vendor Due Diligence: Ensuring the AI provider does not use your inputs to train their global models.

Sources

Source: AI policy gaps putting NZ businesses at risk, expert warns, hcamag.com