AI for Disability Services: Service Agreements and Incident Logs

A provider can use AI to turn an approved service agreement template into a participant-specific draft, and to turn a staff member's rough account into a structured incident log entry, provided names and health details stay out of the prompt and a named manager reads and approves every output before it is used or filed.

The two jobs behave differently. An agreement is a slow, one-off document where AI saves an hour of copying and rewording. An incident entry is fast, sensitive and sometimes time-limited, so the AI's job is narrower: structure the facts, flag what is missing, never decide what happened or what must be reported. Get that split right and the rest of the set-up follows.

Follow me on Instagram@sagnikteaches

Two jobs, two risk levels

Most providers lump "paperwork" together. Separate it before you touch a tool.

Connect on LinkedInSagnik Bhattacharya

The first job is low-risk if you keep identities out. The second is higher-risk because the content is about a vulnerable person, may involve a worker's conduct, and may feed a regulator report. That is why the incident workflow below has more checks than the agreement workflow.

Subscribe on YouTube@sagnikteaches

Keep identifiers out: the label key

The single habit that makes everything else safer is a label key. Before anything goes into an AI tool, replace identifying details with labels, and keep the key in your own records system, never in the tool.

• People: "Participant A", "Support Worker 1", "Family Member 1", "Coordinator".
• Places: "Day programme site", "Participant A's home", "Community outing, shopping centre".
• Dates: keep the day of the week and a relative time ("Tuesday, about 2.15pm") in the prompt; put the real date in the final record yourself.
• Health details: describe what was observed ("grimacing, holding left wrist"), not diagnoses or medication names, unless the entry cannot make sense without them. If it cannot, do that entry by hand.

Say your service has a key sheet where Participant A is a real person with a real record number. The worker writes the note with real names as they always have, the supervisor or a trained admin swaps in labels, the AI structures it, and the admin swaps the real names back into the system of record. It costs two minutes per entry. It also means a mistake in a chat history exposes nothing a stranger could use.

Check your plan before you start, too. Consumer plans of ChatGPT and Claude let you switch off use of your chats for model training in the privacy settings; business plans don't train on your content by default. Neither fact makes it acceptable to paste identifiable participant records, because the legal duty to protect them sits with you, not the vendor. If your regulator or funder requires a data-processing agreement for any tool that touches participant information, get that in place before identifiers go anywhere near it. The data side is covered further in the audit evidence folder tutorial.

Building the agreement template the AI fills in

AI is a good template filler and a poor author of legal terms. So write the fixed terms once, have them checked by whoever advises your organisation on contracts and funder rules, and let the AI handle the variable parts.

A usable template has fixed clauses and marked slots. Fixed clauses: who you are, privacy and information sharing, complaints and feedback, how either side can end the agreement, how changes are agreed, and the responsibilities of each party. Slots: participant label, supports to be delivered, days and times, rates, funding source, review date, representative or decision-supporter details, and any behaviour support or health plan reference.

If you work under the NDIS, check your fixed clauses against the scheme's own participant guidance. It describes a good agreement as covering who it is for, the supports and how they are delivered, what they cost and how the provider is paid, important dates and reviews, both sides' rights and responsibilities, and what to do when you disagree or something goes wrong. It also says a provider can't use a service agreement to contract out of its responsibilities under the NDIS Code of Conduct or consumer law, which is one more reason the AI must never touch a fixed clause. The same guidance says an agreement is required for specialist disability accommodation and recommended, not required, for most other supports, so check which applies before you tell a participant they must sign one.

Put the slots in square brackets and in capitals so nobody, human or AI, can miss them: [PARTICIPANT], [SUPPORTS], [SCHEDULE], [RATES], [REVIEW DATE]. Then a prompt looks like this.

You are helping a disability services provider prepare a draft service agreement.
Use ONLY the template text below. Do not add, remove or reword any clause marked FIXED.
Fill only the bracketed slots, using the details I give you. If a detail is missing,
leave the slot as it is and list it under "Missing information" at the end.
Write in plain English at a reading age of about 12. Use "we" for the provider and "you" for the participant.

TEMPLATE:
[paste template with FIXED labels]

DETAILS:
Participant label: Participant A
Supports: community access, two sessions a week, Tuesday and Thursday, 10am to 1pm
Rates: [from our current price list, entered by the admin]
Review date: 12 months from start

Then list, as bullets, every place where your output differs from the template wording.

That last line is the check that earns its place. Asking for a "differences" list forces the tool to show you what it touched, which is far faster to review than re-reading the whole agreement. If the list includes a FIXED clause, the output goes in the bin.

A filled slot and the mistake it caught

Illustrative: a small provider asks for a draft for a participant who attends a day programme on Tuesdays and Thursdays. The tool returns a clean agreement and a differences list of three items. Two are slot fills. The third reads "Changed 'we will give 14 days' notice' to 'we will give reasonable notice' in the changes clause." That clause was FIXED. The wording sounds friendlier and is exactly the kind of drift that causes a dispute later, because "reasonable" is not a number. The reviewer restores the template text, and adds a line to the prompt: "If you think a FIXED clause needs changing, say so in a note; never change it."

Easy-read and translated versions

Many participants need an easy-read version, and some need another language. AI can produce a first draft of each in seconds. Both carry a specific danger: simplification and translation can quietly change obligations. "You can cancel with 24 hours' notice" may become "you can cancel any time", which is a different promise.

So the rule is: the full agreement is the legal document; the easy-read is a companion, labelled as such, and it is checked line by line by a person who knows the participant, a support coordinator or the participant's chosen helper. For another language, use a qualified translator for the final version. An AI draft is a starting point for their work, not a replacement for it. Ask the AI to keep each easy-read sentence mapped to a numbered clause so the checker can compare them.

What changes by country: Australia, the UK and the US

The structure of agreements and incident logs is similar everywhere. The vocabulary, the regulator and the clocks are not, and an AI tool trained on all of them will happily mix them up. Tell it which one you are in, every time, and keep a short wording table in your template pack.

Two cautions. First, each row is a pointer, not advice: deadlines, categories and thresholds change, so open the current regulator page when you write or update your own procedure and write the deadline into your template from that page. I have deliberately not quoted numbers here for that reason. Second, if you serve people across more than one of these systems, keep one template per system. A single "universal" template is where an AI tool will cheerfully put a safeguarding step from one place into an agreement for another.

The incident log: fields first, words second

A good incident log is mostly fields. Prose is the smallest part. Design the fields yourself before you ask AI to help with anything, because a tool that is allowed to invent the structure will produce a different one each time.

A workable set of fields for a small provider:

1. Entry reference and the date and time it was logged (system-generated).
2. Date, time and place of the incident (real values, entered by a person).
3. Person supported (label in the AI step, real name in the record).
4. Who reported it and who witnessed it.
5. Type: injury, medication, behaviour, missing person, alleged abuse or neglect, property, complaint, near miss, other.
6. Factual description: what was seen and heard, in time order, no opinions.
7. Immediate action taken and by whom.
8. Who was told, and when (family or representative, manager, funder, regulator, police, emergency services).
9. Reportable? Yes, no or unsure, with the name of the person who decided and the time.
10. Follow-up actions with owner and due date.
11. Review: manager's sign-off, and any change to the support plan.

The AI's job covers items 6, 8 and 10 only: tidying the description, pulling the notification timeline into a list, and drafting follow-up tasks. Items 2 to 5, 7 and 9 are decided and entered by people.

The structuring prompt

Below is a staff member's rough note about an incident. Labels replace real names.
Do the following and nothing else:
1. Rewrite the account as a factual description in time order. Keep only what was seen or heard.
   Do not add causes, motives or conclusions. Do not soften or strengthen any wording.
   Quote any words a person said exactly, in quotation marks.
2. List the notifications mentioned in the note, with times.
3. List what is MISSING from the note that a manager would ask about (times, witnesses,
   what happened immediately before, who was told, whether first aid was given).
4. Do not say whether the incident is reportable. Do not give advice.

NOTE:
"Tues about 2.15 at the day site. P A was at the craft table and SW1 asked them to
pack up for the bus. P A threw the scissors, they hit the wall, nobody hurt. SW1 moved
everyone back and I came over. P A was shouting, then calmer after about 10 minutes.
Told manager after."

Illustrative output: a three-sentence factual description in time order; a notification list reading "Manager told after the event (time not stated)"; and a missing-information list that asks what happened immediately before the request to pack up, whether anyone else was within reach, what the support worker said to de-escalate, whether the behaviour support plan was followed, and the time the manager was told. That last list is the real value. A rushed worker rarely volunteers any of it, and a manager asking for each item later costs a lot more than the machine asking now.

What you fix by hand: the AI may call the throwing "an aggressive outburst". That is a judgement. Replace it with "threw scissors towards the wall". It may also leave "calmer" unqualified. Ask the worker what calm looked like, so the record says "stopped shouting and sat down".

The five checks before an entry is filed

Run these in order on every AI-assisted entry. They take about three minutes once the habit is built.

1. Source check. Put the original rough note beside the AI version. Every fact in the output must be in the note. Anything not in the note comes out.
2. Judgement-word check. Search for words like "aggressive", "refused", "violent", "attention-seeking", "non-compliant". Replace each with what was actually seen or said.
3. Number check. Times, durations, counts and locations match the worker's note and any roster or other independent source you have.
4. Reportability check. The manager reads your own written criteria against the facts and decides. They record the decision and time. The AI's summary is never the evidence of the decision.
5. Identity check. Real names go back into the system of record only by the person filing it, and the label key stays out of the tool.

Here is the kind of mistake the source check exists for (illustrative): a worker pastes a note into a chat tool, and the tool "helpfully" adds that the participant "was upset because of the change in routine". Nothing in the note said that. The entry sits in the log for a week before a team leader notices that the participant's family has been told the incident had a cause no one observed. The cause was invented, harmless-sounding and very hard to take back. The source check would have caught it. This is also why a "no causes" instruction is in the prompt above.

Worked example: an 18-participant provider over a year

Illustrative numbers for a small provider supporting 18 participants, with six support workers, a supervisor, a part-time admin and one manager.

Before AI: new agreements take the admin about 90 minutes each, because she copies the last agreement, edits the supports, rechecks every clause and then fixes inconsistencies. There are four new participants and eleven reviews a year, so roughly 22 hours. Incident entries take a supervisor 25 minutes each because workers' notes need rewriting and chasing. The service logs about 14 entries a month: 5.8 hours.

With the workflow above: a new agreement takes about 35 minutes (label the details, run the template prompt, read the differences list, check the easy-read, update the system of record). Over 15 agreements that is about 8.75 hours, so about 14 hours saved a year. Incident entries fall to about 12 minutes, because the structuring prompt does the rewriting and the missing-information list replaces the chasing: 2.8 hours a month, a saving of roughly 3 hours monthly. The numbers are illustrative; time your own first ten entries before you trust any figure, including these.

Cost: ChatGPT Business and Claude Team both start at two seats, at $20 a seat a month billed annually or $25 billed monthly, so a two-seat business plan runs $40 to $50 a month at list prices (as of November 2026). Many providers manage on an existing Microsoft licence instead, since Copilot Chat is included with eligible Microsoft 365 business plans. The larger cost is the manager's review time, which should not shrink. If it does, the workflow has quietly become unsafe.

Monthly trend review without identities

Once you have a month or a quarter of entries, AI can find patterns a busy manager misses. Export the log with only: date (week-level), time band, location type, incident type, and a one-line de-identified description. Never export names.

Here is a de-identified incident log for one quarter (no names, only type, time band and place type).
1. Group the entries by type and by time band and give counts in a table.
2. Name any pattern that appears in at least three entries.
3. Suggest three questions a manager should ask staff or participants about each pattern.
Do not suggest causes as facts, and do not comment on any individual.

Illustrative result: seven of eleven behaviour entries fall in the 2pm to 3pm band at one site, six of them within ten minutes of a transport pick-up. The suggested questions: Is the handover from activity to transport clear? Is there a visual schedule? Are two workers present at that time? Those are questions, not findings. The manager checks them against rosters and talks to the team. A pattern like this is why the log exists, and a human closing the loop is what regulators look for in an audit. The progress notes checklist shows how the same evidence shows up in an audit.

Rolling it out in three weeks

Week one: write the agreement template with FIXED labels and slots, have it checked, and write the incident field list. Decide the label convention and who holds the key. Choose the tool and confirm the plan settings. Week two: run five past agreements and ten past incidents (de-identified) through the prompts and compare the output with what staff actually filed. Note every place the AI got it wrong; add each as a rule in the prompt. Week three: go live on new agreements only, and on incident entries with the manager reading each one. After a month, review the time saved and the errors caught. If the missing-information list stops finding gaps, staff are writing better notes, which is a good result in its own right.

Train staff in two sessions of 30 minutes: how to write a rough note (what you saw and heard, in order), and what never goes into the tool. Put both on one page and pin it to the office wall. If you would rather map the set-up with someone, that is what my AI implementation consultation covers, but nothing here needs it.

Limits to write into your procedure

Put these in the procedure the team signs, so they are not just your opinion.

• AI never decides reportability, and never sends anything to a regulator, funder or family.
• AI never sees real names, addresses, dates of birth, funding numbers or health diagnoses.
• Every AI-assisted document records who reviewed it and when.
• Staff may not use personal accounts for participant work.
• If the tool is unavailable or the manager is unsure, the entry is written by hand the old way. Nothing waits for the AI.
• If a participant or family asks whether AI was used, the answer is yes, with what it did and who checked it.

The last point matters more than providers expect. Families rarely object to tidy paperwork. They object to finding out later that nobody told them. If you also use AI for scheduling or after-hours calls, the same openness applies, and the 90-day plan for a care agency owner shows how to sequence those changes without overloading staff.

What to do when the output is wrong

It will be, sometimes. Keep a simple error log, one line each: date, document type, what the AI got wrong, how it was caught, and the prompt change that followed. After 20 lines you will see two or three repeat offenders, usually invented causes, softened wording, or an altered clause. Each becomes a permanent line in the prompt. If an error reached a participant or a regulator, treat it as an incident in its own right and log it in the same register. That is the same discipline you apply to staff errors, and it keeps the conversation about the process rather than the person.

Questions providers ask before they start

Can AI decide whether an incident is reportable?

No. Reportability depends on your regulator's categories and deadlines, and a wrong call can breach your registration conditions. Use AI to tidy the facts and to show your own checklist against them, then let the named manager decide and record who decided and when.

Should participants sign an agreement the AI has drafted?

Only after a person has read every line against your template and the current rules, and a manager has approved it. Treat the AI draft like a junior's first attempt: useful, fast, and never the final wording. Keep the approved version, not the draft, on file.

Is it safe to paste an incident into ChatGPT or Claude?

Not with names, dates of birth, addresses or health details. Use role labels such as Participant A and Support Worker 1, keep the key in your own system, and check your plan's data settings. If you need real identifiers inside a tool, ask for a business plan with a signed data agreement first.

Do easy-read versions of agreements need a separate check?

Yes. Simplified wording can change the meaning of a cancellation or complaint clause without anyone noticing. Have a support coordinator or the participant's chosen helper read the easy-read version beside the full one before it is used. Keep the full agreement as the signed document.

Further reads

• NDIS Incident Report Template: Can AI Draft It? What a Manager Checks — A manager's checks on an AI-drafted incident report.
• Daycare Incident Reports With AI: Factual, Name-Free Narratives — Factual, name-free incident narratives in another setting.
• AI Answering Service for Home Care Agencies: After-Hours Call-Outs — Handle after-hours calls without losing the hand-off.
• Can AI Write a Care Home Incident Report? Template and Checks — Another incident template, for residential settings.
• NDIS Providers Automation Assessment Checklist: Which Jobs for AI First? — Rank which admin jobs to hand to AI first.
• NDIS Software for Small Providers: Per-User Costs and What You Get — What practice software costs a small provider.
• AI Policy for Aged Care: What to Cover and What Staff Must Not Paste — A checklist for an Australian aged care provider's AI policy: approved tools, the never-paste list, privacy impact assessment, consent and an incident log.
• AI in Occupational Therapy: Funding Letters and Parent Updates — A private-practice OT workflow for evidence-led funding letters and parent summaries that the therapist signs off.
• NDIS Plan Manager Invoices: Checking Claims Against Budgets With AI — Field checks, category matching and a flag-and-hold list for provider invoices, with a person approving every payment and participant data kept tight.
• Supported Living Software: Rotas, Support Plans and Where AI Fits — A plain guide to supported living software: rotas, support plans, daily notes, incident logs, and the jobs where AI adds value and where it should not.
• How Can AI Help in Care Homes? Ten Back-Office Uses — Ten care home back-office jobs where AI saves real time, each with an example, a check and a clear line on what stays with staff.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: NDIS participant guidance on service agreements; NDIS (Incident Management and Reportable Incidents) Rules 2018 on the Federal Register of Legislation; CQC notifications page; UK GDPR Article 9; HHS guidance on cloud computing and business associates; ChatGPT Business and Claude Team pricing pages; OpenAI and Anthropic data-control pages; Microsoft Learn on Copilot Chat (checked 4 November 2026). The NDIS Commission site could not be reached: read its reportable-incident page directly.