Building an AI Complaints Handling Policy Your Staff Will Actually Use
An AI complaints handling policy becomes usable when it defines the decisions staff must make, sets clear boundaries, assigns human accountability and provides realistic practice. Implementation requires more than policy publication. Staff need role-based guidance, scenario training, safe escalation pathways and regular review based on what happens during actual complaint work.
A technically sound policy can still fail at the point of use. The problem is rarely that staff have ignored it. More often, the policy does not answer the operational questions arising when a complaint is received, assessed, summarised, investigated or resolved.
This guide focuses on AI policy implementation for government, regulators, ombudsman offices and enterprise complaints teams. It builds on the foundational principles of disclosure, verification, fairness, confidentiality and governance, then addresses the harder question: how do you make those principles usable under pressure?
Key takeaways
Build the policy around complaint-handling decisions, not abstract statements about AI.
Specify permitted, restricted and prohibited uses for each relevant role and system.
Keep responsibility with an identified person, even when AI supports the work.
Train staff through realistic scenarios that require judgement, explanation and escalation.
Treat uncertainty, workarounds and disagreement as implementation data, not staff failure.
Review actual practice after launch, including records, quality checks and emerging complaint patterns.
Summary table
Implementation area | Weak approach | Usable approach | Evidence to review |
Policy language | Broad principles without operational direction | Decision rules connected to complaint tasks | Staff questions and inconsistent interpretations |
AI boundaries | General permission to use approved tools | Permitted, restricted and prohibited uses by role | System use, workarounds and escalation patterns |
Human review | A statement that humans remain involved | Named responsibility for verification, fairness and final decisions | File records and approval steps |
Staff support | Policy circulation or a generic briefing | Role-based examples, decision guides and facilitated practice | Scenario responses and staff feedback |
Governance | Review only when technology changes | Review after incidents, quality checks and recurring uncertainty | Complaints, debriefs and assurance findings |
Capability | Knowledge testing and policy recitation | Practice identifying risk and explaining fair decisions | Consistency across comparable cases |
Why good AI policies go unused
A good AI policy goes unused when it sits outside the team's real workflow. Abstract language, uncertain ownership, competing procedures and fear of mistakes push staff towards familiar habits. If the policy cannot help someone decide what to do with a difficult file, informal workarounds will usually fill the gap.
The gap often begins with language. A policy may require staff to use AI "responsibly", protect confidentiality and apply human oversight. Those principles matter, but they do not tell a complaint handler whether an approved tool can summarise an attachment, draft an acknowledgement or organise disputed evidence.
Ownership can be equally unclear. Information technology may control the approved tools. Privacy teams may set data restrictions. Legal or governance teams may interpret obligations. Complaints leaders remain responsible for service quality and procedural fairness. Staff can receive different answers depending on whom they ask.
Competing procedures make this worse. A complaint handler may need to reconcile the AI policy with records management, privacy, information security, conflicts, evidence handling, delegations and complaint procedures. Telling staff that every document applies does not resolve a conflict between them.
Fear also drives avoidance. If the consequences of using AI incorrectly are emphasised without a safe way to ask questions, staff may hide uncertainty. Others may continue experimenting outside the approved process because the formal route is too slow or vague. Neither behaviour proves that the team is resistant.
Conflict is not a failure. In this context, disagreement about AI use often signals that ownership, process or risk boundaries have not been properly understood. What helps is a calm, clear and fair method for surfacing those differences early.
Consider a composite and deliberately illustrative scenario. A complaints team has an approved AI policy. It permits an enterprise tool and requires human review, but does not explain whether staff can use the tool to summarise long submissions, identify duplicated issues or draft internal chronologies.
Some officers avoid the tool completely. Others paste de-identified extracts into it. A few create their own prompts and keep notes outside the complaint management system. Managers answer questions case by case, producing different boundaries across the team.
The issue is not deliberate non-compliance. The policy has left ordinary workflow questions unanswered. The resulting workarounds are evidence about what the implementation process missed.
A useful diagnostic is to ask:
Which tasks cause staff to pause or seek informal advice?
Where do different managers give different answers?
Which policy takes priority when requirements appear inconsistent?
Can staff explain what must be recorded after AI is used?
Is there a proportionate escalation route for uncertain cases?
Does the approved process work within actual workload conditions?
These questions move the discussion away from blame. They reveal where clearer decisions, ownership or capability are needed.
Start with the decisions staff make
An effective AI complaints handling policy should follow the sequence of real complaint work. Map the points where staff receive AI-generated material, use AI internally, verify output, protect information, create records and escalate risk. Each point should state the decision, the responsible role and the required evidence.
Do not begin implementation by asking staff to memorise definitions. Begin by mapping a representative complaint from receipt to closure. Identify every moment when AI could affect information, judgement, communication or the integrity of the record.
1. Receiving AI-generated complaint material
Complainants may use generative AI to draft correspondence, organise events or express a concern in formal language. The Queensland Ombudsman advises that people do not need generative AI to make a good complaint and warns that AI output may be inaccurate. It also cautions users about entering personal information into AI tools (Queensland Ombudsman).
Staff should not assume that polished, repetitive or unusually structured material is dishonest. The practical questions are:
What concern is the person asking the organisation to address?
Which facts, documents or outcomes require clarification?
Does the volume or structure prevent the issue from being understood?
Is direct contact needed to confirm the complainant's own account?
Could accessibility, language or communication needs explain the use of AI?
The task is to identify the complaint, not to police writing style. AI-generated language may contain errors, but it may also help a person communicate. Procedural fairness requires staff to test relevant information without making unsupported assumptions about credibility.
2. Using AI to summarise or organise information
Summarisation can appear low risk, yet a summary can omit qualifications, merge separate allegations or give greater weight to repeated material. The policy should tell staff what source material may be processed, which tools may be used and when the original must be checked.
A usable rule is task-specific. For example, AI may support an internal chronology using approved information, but the responsible officer must compare the chronology against source records before relying on it. The chronology should not quietly become the evidence.
3. Checking accuracy and evidence integrity
Verification must be more specific than "check the output". Staff need to know what checking requires for the task.
For factual summaries, checking may require comparison with the full source. For correspondence, it may require confirming names, dates, issues and promised actions. For an analytical output, it may require examining whether relevant evidence was omitted or assumptions were introduced.
A complaint handler should also be able to identify the provenance of important material. If no one can explain where a statement came from, it should not be treated as an established fact merely because it appears in a fluent summary.
4. Protecting confidential and personal information
The Office of the Australian Information Commissioner advises organisations to conduct due diligence before using commercially available AI products and to avoid entering personal, sensitive or confidential information into publicly available generative AI tools (OAIC).
The policy should convert that principle into specific choices. Staff need to know which systems are approved, what information classifications they accept, whether de-identification is sufficient and whom to contact when the answer is unclear.
De-identification is not always straightforward. A rare role, distinctive event or combination of details may identify a person even after names are removed. Staff should not be expected to resolve that risk through intuition alone.
5. Keeping an adequate record
The file should show how AI affected the complaint process where that use is material. Depending on the task and organisational requirements, the record may need to identify the tool, purpose, source information, verification performed, changes made and responsible officer.
This is not an argument for recording every routine interaction without distinction. It is an argument for a record that allows another person to understand how a significant conclusion or communication was produced.
6. Escalating risk and uncertainty
Escalation should be easy to use before harm occurs. Define the circumstances that require advice, such as uncertain confidentiality, proposed reliance on AI analysis, disputed factual output, vulnerable complainants or a material impact on rights and interests.
The escalation path should identify a role, not simply tell staff to contact "the appropriate area". Clarity is kind, especially when someone is managing a difficult complaint under time pressure.
Define boundaries and human accountability
AI may support complaint work, but it cannot hold responsibility for fairness, empathy or an administrative decision. A usable policy distinguishes permitted, restricted and prohibited uses, specifies the human review required for each task and names the person accountable for the resulting communication, assessment or decision.
A single organisation-wide statement about acceptable AI use is rarely enough for complaints teams. Risk depends on purpose, information, context and consequence. Drafting an internal list of issues is not equivalent to recommending that a complaint be declined.
1. Separate permitted, restricted and prohibited uses
Permitted uses are tasks staff may perform within stated controls. These might include improving the structure of non-sensitive internal text or generating questions for human review, provided an approved system is used.
Restricted uses require additional conditions or approval. These may involve summarising complaint records, translating correspondence, analysing patterns or producing draft reasons. Restrictions should state who approves the use and what verification is required.
Prohibited uses should be unambiguous. An organisation may prohibit entering protected information into public tools, fabricating evidence, allowing AI to make final complaint decisions or sending unreviewed AI-generated correspondence.
These examples are not a policy template. Each organisation must define boundaries against its own legislation, delegations, information environment, complaint model and risk settings.
2. Make human review observable
"Human in the loop" is too vague unless the loop contains a real decision. The policy should specify what the reviewer must examine, what authority they hold and what is recorded.
A person who clicks approve without access to the source material is not providing meaningful review. Nor is a manager who assumes the system has already checked accuracy. Human oversight only works when the reviewer has enough information, time and authority to challenge the output.
The Australian Government's Policy for the responsible use of AI in government requires accountable governance arrangements and transparency for government entities within its scope (Australian Government Digital Transformation Agency). Complaints teams still need to translate enterprise governance into file-level responsibilities.
3. Protect procedural fairness
AI can influence fairness before any final decision is made. It may shape which issues are noticed, how evidence is summarised, which cases receive attention and how reasons are expressed.
Staff should ask whether the person has a fair opportunity to understand and respond to adverse information. They should also test whether an AI-supported summary has removed context that matters to the person's account.
Empathy matters here. A technically accurate response can still be procedurally poor if it does not acknowledge the concern, explain the process or respond to what matters. AI may support drafting, but it cannot take responsibility for the relationship between the organisation and the complainant.
4. Assign responsibility by decision
Accountability should attach to a defined decision or action:
Complaint activity | AI may support | Human accountability |
Intake | Organising issues or drafting clarification questions | Intake officer confirms the complaint and immediate risks |
Assessment | Structuring information for review | Authorised officer determines jurisdiction, priority and process |
Evidence review | Creating a draft chronology or identifying possible gaps | Complaint handler verifies sources and resolves disputed facts |
Communication | Producing a draft response | Named officer checks accuracy, tone, fairness and commitments |
Outcome | Assisting with structure or plain language | Delegated decision-maker reaches and owns the decision |
Quality assurance | Identifying files for review | Quality reviewer tests the file and decides any action |
Responsibility cannot be assigned to "the team" in a way that leaves no individual clear about their role. It should also remain proportionate. Not every use requires executive approval, but every material action needs an accountable person.
Turn policy into usable practice
Policy becomes practice when staff can recognise a situation, choose an allowed action and explain why. Role-based examples, short decision guides, facilitated scenario discussions and safe opportunities to test difficult cases are more useful than another long procedure. The objective is consistent judgement, not mechanical compliance.
Start with roles. An intake officer, investigator, team leader, records adviser and decision-maker encounter different AI risks. Generic examples force each person to work out how the policy applies while already managing a live matter.
Role-based guidance should describe the situation, available choices, relevant boundary, required review and record. It should include borderline cases, not only obvious prohibited conduct.
A short decision guide can use a sequence such as:
What task am I trying to complete?
Is the tool approved for this information and purpose?
Could the output affect a person's rights, interests or experience?
What source checking and human review are required?
What must be recorded?
What uncertainty needs escalation before I proceed?
The guide should connect to the policy rather than restate it. Staff need a route from the immediate question to the relevant requirement.
Facilitated scenario discussion is particularly useful where reasonable people may interpret risk differently. A facilitator can pause the scenario, surface assumptions and ask what information would change the decision. This reveals whether inconsistency comes from knowledge, policy ambiguity, role confusion or different risk tolerances.
Scenarios should include realistic pressure. Consider an urgent complaint containing sensitive attachments, a long AI-generated submission with uncertain factual claims, or a manager asking for a rapid summary before a briefing. Remove the pressure and the exercise may test recall rather than judgement.
Teams also need permission to test the difficult edge cases. Good process creates safety. If staff believe that raising uncertainty will make them look incapable, the organisation loses access to valuable implementation information.
The Early Resolution Sequence provides a practical way to work through policy friction before it becomes entrenched:
Clarify the issue: Identify the exact AI use or decision causing uncertainty.
Understand what matters: Examine fairness, workload, confidentiality, evidence and service impact.
Choose the right process: Decide whether the matter needs guidance, coaching, technical advice or a management decision.
Create structure: Identify the decision-maker, information required and timeframe.
Support the conversation: Allow staff, governance and operational leaders to test different concerns.
Document the next step: Record the agreed boundary and feed it into policy guidance.
Not every matter needs the same process. A misunderstanding may need coaching. Conflicting procedures may need a governance decision. A suspected privacy incident requires the relevant incident process, not an informal discussion.
Train for judgement, not recitation
AI complaint management training should help staff identify risk, make defensible choices and explain decisions fairly. Scenario-based, in-house training is effective because the team practises within its own complaint model, statutory context, systems and escalation routes. A policy quiz cannot demonstrate whether someone can handle a difficult case.
Knowledge still matters. Staff should understand approved systems, information restrictions, recordkeeping duties and accountability. But capability becomes visible when they can apply those requirements to incomplete, contested or emotionally charged material.
In-house design allows scenarios to reflect the organisation's actual work without disclosing live confidential matters. Composite cases can preserve recurring decision patterns while removing identifying details. Participants can then discuss the same operational tensions they will face after training.
In my dispute resolution practice, I designed and delivered a five-day accredited mediation program for tribunal-facing staff in a federal government department. The whole cohort trained together inside its own statutory context rather than attending generic external courses. The value was not simply shared attendance. Participants developed a common process and language connected to their real roles.
I have seen the same principle in an ombudsman office, where I delivered in-house communication and early-resolution training based on the office's real complaint patterns. Teams handling emotionally charged contacts gained shared language and structure for difficult conversations without leaving their workplace.
That approach informs the Navigating AI in Complaints and Dispute Resolution program, which I built around fairness, evidence integrity and workload realities. The program runs through public sessions and tailored in-house delivery for regulators and complaints teams. The aim is practical judgement, not overstating what AI can do or treating every use as equally risky.
According to Shiv Martin Consulting's own business records, this work draws on more than 15 years of dispute resolution practice across more than 50 government and business organisations. Those figures describe broader dispute resolution and capability experience. They should not be read as a claim that every engagement involved AI.
Effective exercises ask participants to:
distinguish an AI-generated allegation from evidence supporting it;
identify when clarification is fairer than making an assumption;
decide whether information can enter an approved tool;
find material omissions in an AI-generated summary;
explain why a draft response requires substantive revision;
identify the responsible officer and required record;
escalate uncertainty without abandoning ownership of the complaint.
Assessment should focus on reasoning. Two participants may reach different defensible conclusions if the policy allows discretion. The facilitator's job is to test whether each person identified the relevant risks, followed the required process and could explain the decision.
Shared language is a practical control. When staff use the same terms for source verification, material AI use, human review and escalation, managers can identify problems earlier. Quality assurance also becomes more consistent.
Review what happens after launch
AI policy implementation should be reviewed through actual behaviour, not publication records. Examine staff questions, escalations, workarounds, complaint files, quality findings and recurring uncertainty. Assign an operational policy owner who can resolve ambiguity, coordinate specialist advice and update guidance when technology, complaint patterns or organisational practice changes.
A launch date is the beginning of implementation. Early feedback should be deliberately invited. Ask staff where the policy slows work without reducing risk, where two requirements conflict and which scenarios remain unclear.
Debriefs should occur after unusual or difficult matters, not only after confirmed incidents. A near miss may reveal a weak boundary. A disagreement between experienced officers may expose a policy term that supports competing interpretations.
Quality checks should examine process rather than merely searching for AI use. Useful questions include:
Was the chosen tool approved for the task and information?
Was the source material available to the reviewer?
Did the human review address accuracy and fairness?
Can the file explain how a material output was produced?
Did the communication respond to the person's actual concern?
Was uncertainty escalated through the intended pathway?
Policy ownership must be practical. The owner needs authority to obtain input from complaints, privacy, information security, records, legal and learning teams. They also need a method for issuing interim guidance when a new question cannot wait for a full policy review.
The National Institute of Standards and Technology's AI Risk Management Framework organises AI risk work around governing, mapping, measuring and managing risk (NIST). For complaints teams, that cycle becomes useful when connected to specific files, decisions and staff experience rather than treated as a separate governance exercise.
Updates should be driven by evidence. A recurring clarification request may justify a decision guide. Inconsistent handling may require facilitated practice. A system limitation may require a technical control. A serious procedural issue may require a revised boundary or approval process.
Do not assume that every gap requires more policy text. Sometimes the better response is a clearer management decision, a prompt inside the workflow, a changed system permission or a conversation between teams.
Uncertainty is implementation data, not staff failure
My view is that uncertainty and conflict around AI use should be treated as information about the system. When capable staff reach different answers, the first question should not be who failed to comply. Ask which boundary, responsibility or workflow condition allowed the difference to arise. Clarity is kind.
This position matters because blame suppresses reporting. If staff expect criticism for revealing an informal workaround, leaders may never learn why the approved process is failing. The organisation then retains the appearance of compliance while losing visibility over actual behaviour.
The issue is rarely just the wording of the policy. Workload, role clarity, system access, managerial signals and procedural fairness all shape whether staff use it. A complaints officer may understand the formal rule and still work around it because the approved tool cannot complete a time-sensitive task or the escalation path produces no timely answer.
That does not mean every workaround should be accepted. It means leaders should separate conduct from cause. Address any inappropriate action, then examine the conditions that made it seem workable or necessary.
The Process-Fit Distinctions can help leaders avoid defaulting to the wrong response:
Is this conflict about interpretation, or possible misconduct requiring a formal process?
Does the team need early clarification, or has avoidance already allowed risk to grow?
Does neutrality require hearing different views, while fairness still requires a clear decision?
Does empathy for workload explain behaviour without amounting to agreement with it?
Does psychological safety support candid reporting, even when the conversation is uncomfortable?
Good implementation creates a route for those distinctions to be made calmly. It also gives leaders a way to choose the right conversation, at the right time, in the right structure.
For heads of complaints, HR, L&D and governance, the practical test is simple: can staff apply the AI policy consistently when the facts are unclear, the person is distressed and time is limited? If not, the next investment should be in implementation and capability, not another document.
Shiv Martin Consulting works with government, regulators and enterprise teams across Australia and New Zealand. If your organisation needs facilitated, in-house training that helps complaints staff apply an existing AI policy consistently, you are invited to start with a confidential conversation about the team's context, difficult decisions and capability needs.
Frequently asked questions
What should an AI complaints handling policy tell staff?
It should tell staff which tools and uses are permitted, restricted or prohibited. It should also explain required checking, information controls, recordkeeping, human review, escalation and accountability. The policy becomes usable when these requirements are connected to real complaint tasks and roles.
Can AI make a complaint handling decision?
AI may assist with defined tasks, but the authorised human decision-maker should reach and own the decision. The person must be able to examine relevant source material, question AI output, apply the governing criteria and explain the outcome fairly. An AI-generated recommendation should not become a decision by default.
Should staff disclose every use of AI to a complainant?
Not necessarily. Disclosure should depend on applicable policy, law, materiality and the effect of AI use on the process or outcome. The organisation should define when disclosure is required rather than leaving each officer to improvise. Transparency should be meaningful, not a generic statement that obscures what occurred.
How should teams handle AI-generated complaints?
Focus on the underlying concern, requested outcome and supporting information. Do not assume that polished or repetitive language proves dishonesty. Clarify unclear facts, verify relevant material and communicate directly where needed. A person should not be disadvantaged merely because they used AI to help express a complaint.
What is the best way to train staff on an AI complaint policy?
Use facilitated, role-based scenarios drawn from the organisation's complaint environment. Staff should practise identifying risks, checking output, protecting information, recording material use and explaining decisions. Training should expose unclear policy boundaries and produce feedback for governance owners, rather than testing recitation alone.
How often should an AI complaints handling policy be reviewed?
Review should respond to evidence, not only a fixed calendar. Relevant triggers include new tools, changed organisational requirements, incidents, near misses, quality findings, recurring staff questions and emerging complaint patterns. Regular scheduled review remains useful, but it should be supported by active feedback and assurance between formal reviews.
References
The following sources provide recognised guidance on responsible AI use, privacy, governance and AI-assisted complaints. They should be read alongside the legislation, policies, delegations and information requirements applying to each organisation. Source guidance does not replace organisation-specific legal, privacy, security or records advice.
.png)