AI implementation
What to bring to an AI business assessment, and what to keep back
Prepare for an AI assessment by describing one workflow on a single page that contains no client data. Cover what starts the work, who does it and who approves it, roughly how often it runs, which systems it touches, how it goes wrong and what decision you need at the end. Share more only in stages, as scope and written confidentiality terms are agreed, and never send credentials or bulk client data by email or chat. If the page shows one rule-based task inside software you already own, you may not need a paid assessment at all.
Amulet's booking page says: "Bring one difficult workflow and a short, non-sensitive summary so we can test whether deeper review is useful." It also says: "Leave confidential names, files and data out of the request." Neither line says what a useful non-sensitive summary contains. The sheet below answers that, and it is meant for any supplier's assessment, audit or discovery engagement, ours included. Passages marked "Our recommendation" are Amulet AI's reasoning, not an industry standard or a legal requirement. Nothing here is legal advice. Where a constraint needs interpreting, ask a privacy adviser or a lawyer.
The one-page preparation sheet
Our recommendation: fill in one sheet for one workflow before the first call. Use approximate ranges, describe documents by type instead of attaching them, and write "unknown" where you do not know. An unknown is useful, because it is often what the assessment should find out.
| Item | What to write down | Safe form to share | Why the assessor needs it |
|---|---|---|---|
| Workflow and trigger | A plain name for the work and the event that starts it, such as an email arriving or a job being marked complete | One or two sentences with no client names | It sets the boundary of the assessment and shows where information enters |
| People | Who does the work and who approves the output | Role titles, not names | An AI output needs a named person accountable for it, and an approval gap is a finding in its own right |
| Volume and frequency | How often the work runs and roughly how many items each time | A range such as "a few a day" or "dozens a week", not a system report | It separates work worth building for from work that a rule or a checklist already covers |
| Systems touched | The software involved, and whether you hold admin or export rights in each | Product names and "admin yes, no or unsure", never logins or screenshots showing client data | It decides whether information can get in and out, and whether the answer might be a setting in software you already pay for |
| Input and output document types | What arrives and what must come out, such as a supplier invoice as a PDF, or a reply email | A description of the layout and how much it varies, or a fully invented sample | Structured inputs may need no AI, and free-form documents are where interpretation may be needed |
| Common failure modes | Three to five ways the work most often goes wrong | A short list in general terms | They become the test cases and define the exception path |
| What happens when it fails | Who notices, how it gets fixed, and what the fix costs in time or goodwill | A sentence or two, no client names | Any new design must keep this path, and it is the baseline to beat |
| Decision you need | The choice the assessment should let you make | One sentence, such as "Do we configure what we have, change the process or bring in a supplier?" | An assessment aimed at a decision can be judged afterwards, and a survey cannot |
| Constraints to flag, not interpret | Privacy commitments, client contract terms, record-keeping duties, industry rules | A list of what exists and where it is written down, with no summary of what it means | The assessor must know the limits exist, and interpreting them is for your privacy adviser or lawyer |
| What you have tried | Features in software you already pay for, rules, templates, earlier suppliers | Names and one line on what happened | It stops you paying to rediscover what you already know, and it may show the answer is configuration |
The people who do the work are best placed to write the failure list and the "what happens when it fails" row, so ask them rather than reconstructing it from a manager's desk. Resist writing the solution as the problem. "We need an AI agent to chase quotes" is a solution. "Sent quotes go unanswered and nobody notices until the client rings" is a problem an assessor can test, and it leaves room for the answer that you do not need AI.
The sheet is worth completing even if you never book anyone. Finished, it shows whether you have one rule inside one system, a process that needs changing, or work that crosses systems and reads free-form documents.
A staged sharing ladder
Our recommendation (informed by the OAIC guidance discussed below but not prescribed by it, and not legal advice): share the least that lets the next decision be made, and move up a stage only when its condition is met.
| Stage | What belongs here | Condition before you share it |
|---|---|---|
| A. First problem-fit conversation | The completed sheet in its safe form: roles, document types, ranges, software names and your rights to them | None beyond wanting to test whether a deeper review is useful. Client and staff names, real files and real data stay out |
| B. Scoped, paid assessment with confidentiality terms agreed in writing | Redacted or invented sample documents, process notes and policies, screenshots with client details masked, and supervised or read-only access to look at a system if the scope allows it. If real records are needed, the scope names which fields, how many records, who will see them and what happens to them afterwards | The written scope says what you will receive and how your material may be used, and the confidentiality terms are signed. If personal information or client contract terms are involved, ask a privacy adviser or lawyer first |
| C. Approved implementation only | Real working data for the agreed workflow, and named user accounts set up inside your own systems that you can switch off | A separate go decision with its own written scope, a named approver on your side and a stated exception path. Anything the workflow does not use stays out |
| D. Never by email or chat, at any stage | Passwords and credentials, one-time codes, full unredacted client exports, identity documents | No condition makes sending these this way appropriate. If access is needed, set it up through the user and permission settings inside the system itself |
If someone uses a public chatbot to tidy the summary
A sheet written the way stage A describes should hold no personal information, so the question of what goes into a public chatbot should not arise. If staff are tempted to paste in more, the OAIC's guidance on privacy and the use of commercially available AI products says: "As a matter of best practice, the OAIC recommends that organisations do not enter personal information, and particularly sensitive information, into publicly available AI chatbots and other publicly available generative AI tools, due to the significant and complex privacy risks involved."
The guidance was published on 21 October 2024 and updated on 17 January 2025. It is guidance, not law, and it is written for organisations using commercially available AI products, though it also covers freely available chatbots. It is not about sharing information with consultants or assessors, so this guide uses it only for the chatbot question. The same page says: "Privacy obligations will apply to any personal information input into an AI system, as well as the output data generated by AI (where it contains personal information)." Whether a particular document counts as personal information, and what follows if it does, is a question for a privacy adviser or lawyer.
How to judge the assessment's output
Our recommendation: use the "decision you need" row of your sheet as the test. A useful assessment returns something you can check against it.
| You should walk away with | Test it by asking |
|---|---|
| A decision about this workflow: go, no-go, change the process, configure software you already own, build internally or use another supplier | Which of these does the report choose, and what would have made it choose differently? |
| The evidence behind the decision | What was examined, what was assumed and what could not be checked? |
| A named owner on your side | Who in our business owns this afterwards, and can they pause it? See who owns an AI workflow after launch |
| The exception path | What happens to each failure case on our sheet? |
| A bounded first step | What is the smallest test, what counts as passing, and when would we stop? See the AI pilot acceptance checklist |
If the recommended route involves a commercially available AI product, the OAIC guidance says organisations "should conduct due diligence to ensure the product is suitable to its intended uses". It names several things that due diligence should include, among them "who will have access to personal information input or generated by the entity when using the product". Ask whether the output addresses them.
Warning signs
Our recommendation: treat each of these as a reason to ask for clarification before you continue.
- A technology shopping list where a decision about your workflow should be.
- No realistic no-go outcome, so that every path ends with you buying something.
- Requests for credentials or bulk data before the scope is agreed.
- A generic maturity score with no workflow-specific decision attached.
- A first step with no test and no point at which you would stop.
- A scope that does not say what you will receive or how your material may be used.
Amulet's AI Business BEEP is one paid assessment you can hold to these checks. Its public page describes a "fixed-scope discovery engagement" producing a "decision-ready opportunity brief covering the workflow, systems, feasibility, controls and recommended first step". The same page says: "A review can end with a no-go, a process change, an internal build or another delivery partner." It also says: "The engagement scope states what Amulet will deliver and how the material may be used." Apply the table and the warning signs to it as you would to any other supplier.
You may not need a paid assessment
If the sheet shows a single rule-based task inside one system, such as a reminder that fires when a date passes, look at the settings of software you already own, or write a simple rule, before paying anyone to assess it. Configure software, automate a rule, or build an AI workflow? sets out how to choose between those routes.
Two outside sources point the same way. Google's Rules of Machine Learning opens its first rule with "Don’t be afraid to launch a product without machine learning." and says of machine learning that "it requires data". That guide is written for engineers building machine learning systems, not for buyers of assessments, so read it as an argument about order: start with the simplest thing that works. The OAIC guidance makes a related point for organisations choosing commercially available AI products: "AI products should not be used simply because they are available."
Our recommendation: pay for an assessment when the sheet shows something that a settings page and a simple rule cannot settle, such as work that crosses several systems, reads free-form documents, has several kinds of exception or has no single owner. Whichever route you take, compare quotes on the same scope. AI implementation costs in Australia and how to choose an AI implementation partner cover how.
A hypothetical filled-in sheet: quote follow-up in a trades business
Hypothetical example, not a real business or client. Every entry below is invented to show the level of detail, and none of it is a result.
| Item | Entry |
|---|---|
| Workflow and trigger | Quote follow-up. It starts when a sent quote has had no reply for a few working days |
| People | The office manager does the chasing. The owner approves any change to price or scope. The estimator answers technical questions |
| Volume and frequency | A few dozen quotes open at any time and a handful of follow-ups on a normal day. Invented range |
| Systems touched | Email, the quoting module of the job-management software, and a shared spreadsheet of open quotes. The owner has admin rights in the job-management software, export rights are unknown, and an outside IT provider administers email |
| Input and output document types | In: a quote as a PDF, and client replies by email, sometimes with photos or a changed scope. Out: a follow-up email draft and an updated status line in the spreadsheet |
| Common failure modes | Chasing a client who already accepted by phone; chasing about an old version after the quote was revised; a client's question sitting unanswered in the shared inbox; a quote lapsing past its validity date unnoticed; two staff chasing the same client |
| What happens when it fails | The office manager checks the spreadsheet when time allows, usually at the end of the week. A missed follow-up tends to come to light when the client rings |
| Decision you need | Can reminders and status tracking be handled in the job-management software, or does anything need an outside supplier? |
| Constraints to flag, not interpret | Client contact details are personal information covered by the business's privacy policy. Some commercial clients' contracts limit how their documents are shared. Quotes must be kept for the business's record-keeping period. None of this is interpreted here, and it goes to the accountant or a lawyer |
| What you have tried | The owner thinks the job-management software has a quote reminder setting but has not checked. A calendar reminder routine was dropped in busy weeks |
This invented sheet points first to configuration. The trigger is a date and the rule is simple, so the first step is to check whether the job-management software can send the reminder and track status. A paid assessment would earn its place only if that check fails, or if the business wants replies read and drafted from free-form emails. That is a reading of an invented sheet, not a finding about any real business.
Limits of this guide
The sheet, the ladder and the warning signs are Amulet AI's recommendations. They have not been validated against a sample of assessments, and they do not replace advice from a privacy adviser or lawyer where personal information or contract terms are involved.
Where to take the sheet next
If the finished sheet points to a settings change or a process change, start with that change, and you may not need a supplier. If it points to work that crosses systems or reads free-form documents, take the non-sensitive version to the first call with whichever supplier you are considering. With Amulet, that is a 30-minute problem-fit request. No software brief is required, and the sheet is one way to write the "short, non-sensitive summary" it asks for.
Sources
A practical next step
Put AI to work with the operating boundary visible.
Approvals, evidence and the rollout path should be mapped to the real workflow.
Discuss your first AI workflow