AI audit for business: scan or audit

A process scan helps you decide whether a workflow is worth automating. An audit goes further: it describes what to build, how to test it and what suppliers should quote. You keep the audit and can use it when choosing a supplier.

Which one you need depends on how much is already known about the work.

When to choose a scan or a audit

For an early assessment, a scan may be enough. If you need to compare build proposals, ask for a audit with the scope and acceptance checks that each supplier will price.

What the process scan produces

The scan records how the work happens today: what arrives, which systems and people handle it, where it repeats and what happens to exceptions. It identifies the owner and the constraints on a build. These may include inaccessible data, unclear authority, manual approvals, retention rules or an outcome that nobody knows how to measure.

The conclusion can be one of several paths:

• request a narrowly scoped automation proposal;
• commission an audit;
• improve the source data or process first; or
• pause because the expected value and control are not clear.

What the paid audit contains

A audit describes the proposed system in enough detail to quote and test it. It normally covers:

1. Process and users: the current flow, roles, handoffs, exceptions, and the first release boundary.
2. Data and sources: where inputs come from, how they are structured, which permissions apply, and what quality work is required.
3. System behavior: triggers, transformations, model or search steps, tools, human approvals, failure states, and notifications.
4. Interfaces and ownership: systems to connect, records to create, access roles, logging, retention, and who maintains each source.
5. Acceptance: representative cases, expected outputs, refusal or escalation rules, performance checks, and the person who signs off.
6. Delivery scope: sequence, dependencies, assumptions, risks, and the commercial scope used for the build proposal.

Another supplier should be able to read the document and understand the same requirements. Leave the model choice open where the scope does not depend on a particular model.

Price, ownership, and scope

Confirm the price, inclusions and next steps in writing before commissioning the document. The audit should remain yours whether Syntalith or another supplier builds the system.

Ask for assumptions beside the scope. A quote that excludes source cleanup, permissions, approval screens, monitoring, or user onboarding may look precise while moving the hard work into change requests. The pricing page gives the current service structure; the proposal should define the actual project.

When a direct proposal is enough

A direct build proposal may be the right next document when the workflow has one owner, the systems are known, the input and output are stable, and the acceptance cases are easy to write. Keep the first release narrow and put exclusions in the proposal.

Request a audit when the proposal would otherwise rely on guesses. Typical signals are several departments, source permissions that differ by role, unclear exception handling, a new record or approval state, competing suppliers, or a budget request that needs a defensible scope.

What the process owner needs to check

A audit is worth paying for when resolving uncertainty now can prevent more expensive changes during development. It gives the buyer and supplier a shared description of the workflow, data, controls and acceptance tests, with a boundary around the first release.

The process owner still needs to check that the description matches daily work, that the proposed actions are allowed and that the test cases represent what the team handles.

What acceptance looks like

Write acceptance before development starts. Include ordinary cases, missing inputs, contradictory sources, permission restrictions, failed integrations, and a handoff to a person. Define which output the system may create automatically and which output it may only propose.

For systems that use models, evaluate source selection, structured fields, refusal behavior, access control, and the action taken after an error. The NIST AI Risk Management Framework is a useful reference for governance, measurement, and monitoring. It does not provide a project-specific acceptance threshold.

When to pause

Pause the build if the process has no accountable owner, the source data cannot be accessed lawfully, the desired outcome has no acceptance test, or a wrong result would trigger an action with no review or rollback. Use the scan to identify which of those conditions must be resolved before a build can proceed.

Privacy and access decisions belong in the scope from the beginning. The GDPR text is the primary reference for personal-data obligations; involve the people responsible for your organisation's assessment.

The AI process audit service describes the paid analysis and current price. The current system demos show examples of workflows and operator review.

FAQ

Is an AI audit the same as a security audit? No. A process scan or audit describes a candidate workflow, data, controls, and acceptance. Security, privacy, and regulatory reviews may be separate workstreams.

Can a audit guarantee a successful implementation? No. It reduces ambiguity and makes acceptance testable. Source quality, integration constraints, user adoption, and operating ownership still affect delivery.

Can we take the audit to another supplier? The client should be able to use a client-owned document for comparison. Confirm licensing and handoff terms in the written proposal.

Sources

• NIST AI Risk Management Framework 1.0
• NIST AI RMF: Govern, Map, Measure, and Manage
• GDPR, Regulation (EU) 2016/679