A practical audit for AI-built software

The first audit of an AI-built application should not begin with whether the code is elegant. It should begin with whether the system can be understood and operated.

This guide is deliberately proportionate. It is designed for a small business or startup application, not a nuclear command system wearing a SaaS logo.

1. Establish what the application is for

Write down, in ordinary language:

• who uses it;
• what important outcome it supports;
• what data it handles;
• what would happen if it became unavailable;
• what would happen if it behaved incorrectly.

This gives every later technical concern a business context. A duplicated CSS rule and an exposed customer export are not equally important, no matter how enthusiastically a linter complains.

2. Map the runtime

Identify every place the system runs or stores state:

• web application hosting;
• APIs and background workers;
• databases and object storage;
• authentication providers;
• queues and scheduled jobs;
• domains, DNS and access policies;
• external services with credentials or webhooks.

Record where each resource lives, which account owns it and how current state can be inspected.

3. Find the authoritative configuration

Search for repeated or contradictory configuration across:

• repository files;
• environment variables;
• provider dashboards;
• CI/CD settings;
• copied deployment scripts;
• local developer instructions.

For each important value, decide where authority belongs. Do not solve this by copying every value into another file and declaring victory.

4. Trace one important workflow

Choose a business-critical path—for example, receiving an order, importing a file or publishing a listing—and trace it from request to durable outcome.

At each step, ask:

1. What validates the input?
2. What happens when the dependency is slow or unavailable?
3. Can the operation run twice safely?
4. Where is failure recorded?
5. How would someone recover or retry it?

One well-chosen trace often reveals more than a broad code review because it crosses the boundaries where assumptions tend to leak.

5. Inspect access and secrets

Confirm:

• production secrets are not committed;
• credentials have the minimum useful permissions;
• former users and abandoned integrations no longer have access;
• administrative paths require appropriate authentication;
• logs do not expose secrets or sensitive records;
• there is a known process for rotating credentials.

Do not rotate production secrets during an exploratory audit unless the change is explicitly planned and recoverable.

6. Check delivery evidence

For the current production version, find evidence for:

• the source commit or release;
• the build result;
• the deployment result;
• the environment that received it;
• the currently serving version;
• a basic behavioural or health check.

A green build is not the same thing as a healthy deployment. Keep those evidence classes separate.

7. Produce a bounded improvement plan

Group findings into three categories:

• Immediate risk: credible security, data-loss or availability problems;
• Operational drag: recurring confusion, manual work or poor recovery;
• Later improvement: worthwhile quality work that does not block safe use.

Then choose the smallest coherent work packet that materially improves the system. Avoid turning the audit into an excuse to rewrite everything in the reviewer’s favourite framework.

The result you want

A useful audit leaves you with:

• a map of the running system;
• the important business workflows;
• clear authority for critical configuration;
• current access and deployment evidence;
• a short list of prioritised improvements;
• enough durable context for another person to continue.

That is a much stronger foundation for the next AI-generated feature than another thousand lines of code nobody has yet learned to operate.