An AI audit for your Los Angeles business process
An AI audit examines how a business process actually works, where AI is involved, and what evidence supports the result. Connor MacIvor helps Los Angeles owners inspect information sources, permissions, handoffs, and failure behavior. The review identifies specific gaps and the next checks needed before changing or expanding the system.
What are we trying to find in an AI audit?
The audit asks whether the system is doing the job the business believes it is doing. A dashboard may show completed conversations while staff have a growing list of unresolved requests. That difference matters. Begin by defining the promised result and tracing how the system claims to reach it.
Choose a process narrow enough to inspect. A Long Beach business might review inquiry routing from the website to the assigned employee. An office elsewhere in the city might examine drafts prepared for customer replies. The review should distinguish observed behavior from assumptions and missing evidence. It should not turn a brief inspection into a claim that every part of the business has been checked.
What evidence should we gather before the review?
Start with a process description, the approved instructions, and examples of the result. Include the people responsible for operating and reviewing it. A screenshot can show a status, but it may not show whether the destination received the information. Identify which records would establish that final step.
Use redacted material for the initial discussion. If deeper inspection is agreed, define the permitted access and records before beginning. An audit does not automatically authorize changes to customer systems. Keep the source and date of each observation clear. An old successful test may explain how the system was intended to work, but it cannot by itself confirm how the current version behaves.
How do we trace a request through the business?
Follow the request from entry to its intended result. Identify the original message, any interpretation or transformation, the assigned destination, and the person who acts on it. At each point, ask what proves the handoff happened. A sent notification and an acknowledged request are different observations.
For a South Bay service team, the trace may cross an office inbox and a dispatcher queue before reaching someone in the field. Check whether the information remains usable throughout that path. A missing address or unclear request can stall work even when every connection reports success. Record the exact stage where the evidence ends, so the next investigation has a concrete starting point.
How are the assistant's information sources checked?
Find the instructions and reference material the system actually uses. Compare them with the business's approved policies. Look for outdated hours, conflicting service descriptions, unclear coverage boundaries, and answers that nobody currently owns. A response cannot be dependable if its source is unsettled.
Test questions that require the system to recognize a limit. Ask about a service outside the approved description or a detail absent from its references. Inspect whether it acknowledges uncertainty or supplies an unsupported answer. Keep the question, expected behavior, and observed response together. That evidence helps separate a source problem from a workflow problem and makes the eventual correction easier to verify.
What do permissions and ownership tell us?
Review who owns the relevant accounts and who can change instructions, connections, or outgoing messages. The person using a workflow may not be the person authorized to approve its behavior. That distinction should be visible. Unclear ownership can leave a broken process running because everyone assumes someone else is watching it.
Compare the access granted with the work required. Note permissions that need further examination by the account owner. Do not change them during an inspection unless that action has been separately authorized. The audit should also identify who receives failures and who can pause the process. Responsibility needs a named role and an actionable route, rather than a general expectation that the team will notice.
How do we examine failures without disrupting customers?
Agree on a controlled test approach. Use approved examples and an appropriate test path before introducing unusual requests. The review should not generate real customer messages or alter live records merely to see what happens. Where a safe test is unavailable, document the gap and the conditions needed to inspect it.
Useful cases include missing information, repeated requests, unavailable destinations, and instructions that require a human decision. Observe the result in the receiving location. A Westside office may discover that an alert exists but reaches an unattended account. That is an operational finding. Record what was observed, its likely effect, and what still needs confirmation before assigning a remedy.
How should findings be prioritized?
Explain each finding through the work it can affect. An unsupported customer promise may need attention before an awkward internal label. A failed handoff may matter more than a cosmetic problem in the dashboard. The owner needs to understand the consequence and the evidence, not just a list of technical concerns.
Give each finding a responsible owner and a concrete next action. Separate a verified failure from a question that needs more access or testing. Describe what would count as a successful correction. If the system should stay within a narrower scope while a problem is investigated, state the reason. The review supports a decision; it does not silently expand the authority of the person conducting it.
What happens after the audit is complete?
Review the findings with the person who can authorize the next step. Some issues may need better instructions, staff practice, or a change to the underlying process. Others may call for implementation work. Do not assume that every finding requires a new tool. Correcting the source of a problem is more useful than adding another screen around it.
Retest the affected behavior after an approved change and attach the result to the original finding. Keep unresolved questions visible with their owners. Connor uses the audit to establish what is known before building or expanding a workflow. Bring the process you want examined, what you believe it does, and the point where the available evidence stops convincing you.
What else should you know before we talk?
Can an audit review something we already built?
Yes. The review can inspect an existing workflow against its intended purpose, approved instructions, and available evidence. Scope and access must be agreed first.
Will the audit change our live system?
Inspection does not authorize changes. Any test or correction that affects live operations needs an approved scope and a controlled method.
What if we cannot provide enough evidence?
The finding should identify the evidence gap and the next check needed. Missing records cannot be treated as proof that the system worked.
Is this a security or legal certification?
No. This is a scoped operational review of the agreed business process. Specialist assessments require their own qualified review and defined scope.
How do we confirm that a finding was fixed?
Repeat the relevant test and inspect the destination. Keep that result with the original finding so the owner can see what changed and what remains unresolved.