The AI policy debate needs the detail from your working day

If you work in-house, you probably have a more useful contribution to the AI debate than you think. It might be the supplier questionnaire nobody can answer consistently. It might be the service that became faster for staff but harder for customers to challenge. It might be a genuinely good pilot that stalled because nobody could explain who was responsible for maintaining it.

Those examples rarely sound impressive in a strategy presentation. They are, however, the material that helps explain what businesses need from policy, public services and the market. Broad support for innovation is easy to express. Explaining the particular obstacle that prevents a useful system from working is much more valuable.

South Australia's Royal Commission into Artificial Intelligence published its Scoping Paper on 29 October 2026. It is seeking initial responses by 30 November 2026, with advice and recommendations due to government by 1 July 2027. The paper describes a forward-looking policy inquiry, rather than one principally examining past wrongdoing. Its interests include business, work, education and public services, with a focus on what South Australia can influence. [1]

For legal and procurement teams, that provides a timely reason to organise experience that otherwise stays scattered across projects. The approach below is my practical suggestion for doing that. It can help an organisation contribute to an inquiry, but it can also improve its own decisions without making any public submission.

Start with the problem before choosing a policy position

A familiar internal conversation begins with someone asking whether the organisation supports more AI regulation. That is a difficult place to start because different people are answering different questions.

One person is thinking about a useful drafting assistant. Another is thinking about automated decisions affecting customers. A third is thinking about the time spent negotiating access to business records. Agreement or disagreement at that level tells you very little about what should change.

Start with a specific piece of work instead. What was someone trying to achieve? What happened? Which part involved AI? What prevented the outcome from being useful, reliable or accessible? Who experienced the consequence?

Consider a hypothetical regional supplier trying to respond to a government tender. The business uses AI to help organise its answer, but then spends several days interpreting inconsistent questions about training data, hosting and subcontractors. The problem might be unclear procurement language rather than a shortage of enthusiasm for AI. A recommendation for clearer questions follows from that experience. A sweeping claim that regulation prevents innovation does not.

The more precisely you describe the difficulty, the easier it becomes to propose something that another person could actually implement.

Build a small collection of cases rather than a grand narrative

Ask a few teams for examples that turned out differently. Include something that worked well, something that failed or was abandoned, and something still unresolved. That makes it harder for the exercise to become a promotional account of a favourite project or a catalogue of everything that frightened the organisation.

For each example, capture a short account under six questions:

1. What task was the organisation trying to improve?
2. What did the AI system do, and what remained with people?
3. What changed for the staff or customers involved?
4. What evidence supports that account?
5. What obstacle or benefit appears relevant beyond this one project?
6. What practical change would help, and who could make it?

Keep the source material behind the account. A concise summary is useful only if someone can find the records that explain it. Preserve the relevant dates, the version of the process being discussed and any limitations in the evidence.

You do not need a polished case study for every item. A carefully documented unresolved question can be more useful than a confident success story with no baseline.

Separate observation from explanation

Imagine a hypothetical team reporting that a procurement review took longer after introducing an AI assistant. That observation might be accurate. The conclusion that AI caused the delay still needs work.

Perhaps the team started reviewing more documents. Perhaps the new process exposed departures that had previously gone unnoticed. Perhaps the output was poor and required extensive correction. Perhaps the rollout coincided with a staffing change. Those possibilities lead to very different lessons.

A useful case separates what the records show from what people think explains it. For example, the record might show that review time increased during a six-week pilot. Staff interviews might suggest that checking unsupported recommendations was the main cause. That is a more honest account than presenting the explanation as a measured fact.

Also record the alternative you compared against. A new process can look inefficient against an imaginary version of the old process that had no mistakes, interruptions or rework. Equally, a weak existing process should not become an excuse to accept any new system that appears slightly better.

Legal can help keep these distinctions visible without turning every account into an expert report. The aim is an explanation that can withstand an ordinary follow-up question.

Ask who receives the benefit and who carries the extra work

An organisation may save time while moving effort to somebody else. A faster intake tool could leave customers correcting errors. An automated contract summary could reduce initial reading time while increasing the work required from a specialist reviewer. A central team might report a saving while regional staff absorb additional administration.

These are questions to investigate, not assumptions about what AI always does. Ask the people at each end of the process what changed. Look beyond the person who sponsored the project and the person who administers the licence.

A practical example is a hypothetical customer service tool that produces a quick response but gives customers no clear way to challenge a wrong answer. The business may measure response speed and miss repeat contacts. The customer may experience a closed loop in which each request produces the same explanation.

That case could support a specific recommendation about escalation routes or service measurement. It does not establish that every automated service is harmful. Keeping the account proportionate makes it easier for readers to understand both the opportunity and the design problem.

It also improves internal investment decisions. A saving that depends on uncounted work somewhere else is a fragile basis for scaling a service.

Turn a complaint into a workable recommendation

The most useful recommendations connect an observed problem to an achievable response. They identify who should act, what should change, the likely burden of doing it and how someone would know it helped.

Take inconsistent supplier questions. An organisation might recommend a common set of plain-language definitions for a particular procurement category, with additional questions reserved for higher-risk uses. That proposal is more specific than asking government to simplify everything. It also leaves room for a smaller supplier to explain its actual service instead of answering a questionnaire written for a different kind of system.

Test the recommendation against an awkward case. Would it still work for a small regional business? Would it exclude a useful new provider? Would it create an easy way for a supplier to avoid a necessary check? Would the same outcome be achieved more cheaply through guidance, training or a better purchasing template?

Be clear about the trade-off you are prepared to accept. If more information is required before a system is purchased, someone must prepare and assess it. Explain why that cost is justified for the particular use. If you recommend a lighter process, explain how serious issues would still be identified.

Readers can disagree with a balanced recommendation and still learn from it. An assertion that a change has benefits and no costs gives them much less to work with.

Stay within the inquiry you are addressing

The Scoping Paper expressly excludes data centres and matters primarily within Commonwealth responsibility, including national security, financial market stability, critical national infrastructure, intellectual property and copyright. It asks contributors to help refine its priorities rather than treat its proposed themes as final. [1]

That scope matters when choosing an example. A detailed submission on an issue outside the inquiry's remit may be less useful than a short account of a problem the relevant government can address. Check the actual terms before investing in a long response.

For an internal exercise, use the same discipline. If the issue is your own purchasing practice, do not wait for legislation to fix it. If the issue depends on a national rule, distinguish that from a proposal for a state agency. If several bodies would need to act together, say so rather than assigning the whole problem to whichever organisation happens to be consulting.

An inquiry also gives organisations a reason to compare experiences, without pretending that its existence settles the policy debate. A question being asked is not a finding. A recommendation sought is not an enacted obligation. Keep those categories separate in board updates and supplier discussions.

Decide what can safely leave the organisation

A public submission is a different document from an internal lessons-learned note. The Commission's written-submission guideline says submissions will be published, with confidentiality requests considered individually. It requires submissions through the online tool rather than email. Its separate information-handling guideline also explains that material may appear in reports and that records will ultimately be transferred for archiving. Read the current guidelines before providing anything. [2][3]

As an internal precaution, review proposed examples for personal information, commercially sensitive detail, legal advice, contractual restrictions and allegations about identifiable people. Do not assume that removing a name makes a small project unrecognisable. Dates, locations and a distinctive service description can still identify the participants.

It may be possible to explain the process problem using an aggregated account, a carefully labelled hypothetical or a narrower description. Do not label a hypothetical as an actual case. Do not remove context that changes the meaning of what occurred.

Where confidentiality or privilege is important, get advice on the particular material and disclosure route. A request for confidential treatment should not be treated as a substitute for that assessment. Keep the approved external version separate from the fuller internal records.

Give the work a clear owner and a manageable boundary

This does not need to become a new organisation-wide reporting program. A focused session with Legal, Procurement, a business owner and someone who actually uses the relevant process may be enough to identify two or three worthwhile examples.

Agree who will verify the facts, who can approve the organisation's position and who will make the final decision about any external submission. Give contributors a short template and a realistic cut-off. Avoid asking every team for everything it has ever done with AI.

Before finalising, ask someone outside the project to read the account. Can they explain the problem without a briefing? Can they distinguish measured results from expectations? Do they understand what action is proposed? If not, more adjectives will not help. Add the missing facts or narrow the claim.

Include a contact within the organisation who can explain the example later. A case prepared entirely by a communications team can lose the qualifications that the operational team considers important. Before approval, return the factual account to the people who supplied it and ask them to check what is missing, not merely whether it reads well. Record any disagreement that remains material. A polished consensus is not worth creating if it erases the uncertainty the example was meant to explain.

There is value even if the organisation decides not to submit. The exercise can reveal a confusing supplier requirement, an unsupported benefit claim or a workable process that other teams could reuse. Keep an internal action list for those findings so the effort does not end when the consultation closes.

The public conversation about AI needs people who can describe the ordinary details of adopting it. A clear account of where work improved, where it became harder and what would make a difference is a useful contribution. In-house teams are well placed to assemble that account because they see the gap between the proposed system, the agreement and the way the service is actually used.

For teams organising the contracts and supporting documents behind those experiences, Contract Cloud offers a workspace for contract review and management. Book a Demo to discuss whether it suits the way your team keeps and reviews that material.

Sources

[1] South Australian Royal Commission into Artificial Intelligence Scoping Paper, 29 October 2026. Current inquiry scope, dates and initial consultation position.

[2] Practice Guideline on providing a written submission, accessed 1 November 2026. Submission route, publication and confidentiality process.

[3] Practice Guideline on privacy and handling of information, accessed 1 November 2026. Information use and records handling.