An AI-built internal tool is not automatically insecure. It is also not automatically safe. The honest answer to whether it can hold client data is: it depends entirely on decisions nobody made on purpose, and that is exactly the problem.

When a staff member uses an AI coding assistant to build an app, the tool produces working code quickly. What it does not produce, unless specifically asked, is secure authentication, encrypted storage, proper access controls, or an audit trail. Those things require deliberate decisions. An AI assistant will happily generate a functional app without any of them, because functional was the only thing requested.

Where the Risk Actually Lives

The danger is rarely in the AI-generated code itself being malicious or obviously broken. The danger sits in what was never asked for.

Authentication. Many quickly built internal tools use a single shared password, or no login at all, because adding proper authentication takes extra effort the builder did not know to request.

Storage location. Data frequently ends up in a spreadsheet, a personal cloud folder, or a database with no access restriction, because that was the simplest path to a working result.

Access logging. Enterprise systems record who accessed what and when. A staff-built tool almost never does, which matters significantly if client data is ever involved in an incident and you need to establish what happened.

Backup and recovery. If the only copy of client information lives in a tool one person built on their laptop, there is no backup strategy behind it at all.

The Privacy Act Angle

Under the Privacy Act 1988, Australian businesses holding personal information have obligations around how that information is stored and protected, regardless of which system it sits in. An AI-built internal tool holding client names, contact details, financial information, or health data is subject to exactly the same obligations as your core business systems. It does not get a pass because it was built quickly or informally.

If that tool is ever involved in a data breach, the fact that it was staff-built rather than commercially procured does not reduce your notification obligations under the Notifiable Data Breaches scheme. It may make the breach harder to detect, scope, and explain, which is worse, not better.

A Simple Test Before Client Data Goes Anywhere Near It

Before any AI-built tool touches genuine client data, run it through four quick questions.

• Does every user need their own login, and is that login enforced?
• Is the data encrypted both in storage and when it moves between systems?
• Is there a record of who accessed or changed the data and when?
• If the device or account it lives on is lost, is there a recoverable backup?

If the answer to any of these is no, the tool is not ready to hold client data yet, however useful it is for internal, low-sensitivity tasks.

Fixing an Existing Tool Without Starting Over

The good news is that most of these gaps can be closed without rebuilding the tool from scratch. Adding proper authentication, moving data into a managed, access-controlled location, and switching on logging are usually achievable retrofits rather than full rebuilds. The key is having someone with security expertise review the tool specifically for these gaps, rather than assuming that because it works, it is fine.

How Otto IT Helps

Our managed cybersecurity services include reviewing staff-built and AI-generated applications against exactly this checklist, and our team can retrofit proper access controls without necessarily rebuilding the whole tool. If you have an AI-built app that has quietly started holding real client information, get in touch before it becomes the subject of an incident rather than a review.

Frequently Asked Questions

Is every AI-built app automatically insecure?

No. Many are perfectly adequate for low-sensitivity internal tasks. The risk rises specifically when client data, financial records, or health information enters the picture without the right controls being added deliberately.

Can we keep using the tool while it gets fixed?

In most cases yes, provided client data is temporarily removed or restricted until the gaps are closed. A short pause on sensitive use is usually safer than an abrupt shutdown of a tool staff rely on.

Who is liable if an AI-built tool causes a data breach?

The business holding the data carries the obligation under the Privacy Act, regardless of who built the system or how informally it started. This is exactly why a quick review before sensitive use matters.