Independent AI audit for enterprise AI systems

What a real AI audit covers

• System and data flow: models, prompts, retrieval, tools, permissions, human gates, and vendor dependencies.
• Control design: whether the claimed controls exist in code and operations, not only in policy.
• Control testing: repeated runs of critical scenarios, failed tool calls, permission boundaries, and escalation paths.
• Trace and evidence review: whether an answer can be reconstructed from retained inputs, evidence, model versions, and approvals.
• Discrepancy log: each finding has severity, evidence, owner, and a remediation action.
• Framework mapping: NIST AI RMF, ISO/IEC 42001, EU AI Act readiness, SOC 2 expectations, or the client's internal standard.

Deliverables

• Audit plan and evidence request list.
• System and control map.
• Test matrix with k ≥ 3 runs and recorded traces.
• Severity-ranked findings register.
• Control matrix mapped to the agreed framework.
• Remediation roadmap with P0/P1/P2 owners.
• Board-ready readout and evidence pack.

What it is not

It is not a certification, a legal opinion, or a substitute for an accredited audit body. It is independent engineering evidence that helps you prepare for those reviews and fix what would fail them.

How the audit runs

1. Audit plan: define the system boundary, the control framework, the evidence request list, and the acceptance criteria.
2. Test: review architecture and traces; run critical scenarios at k ≥ 3; test permissions, failed tools, escalation, and rollback.
3. Report: document discrepancies, map controls, assign severity and ownership, and present the evidence pack to the accountable executive.

The client provides access to architecture, traces, policies, and a named owner. The audit does not replace management's responsibility for the system.

What to prepare

Bring the system map, model and prompt versions, retrieval sources, tool permissions, incident log, and the policies that claim to govern the system. Name one engineering owner and one executive sponsor. If the evidence does not exist, that is a finding, not a blocker.

The output is designed for a risk committee, a customer security review, or a board update. It is written in plain language first, with technical evidence attached, so the accountable executive can act without translating engineering notes.

Built for US and Canadian buyers

US enterprise procurement and Canadian model-risk reviews both ask the same question: show me the evidence, not the policy. The engagement is remote-first with ET/PT overlap. Invoices are USD; CAD settlement is available through Wise; Deel supports the contract where required.

When to hire

Before a production release, a customer security review, an insurer or investor diligence process, an EU AI Act readiness review, a SOC 2 audit, or a board update. If the system is already in production, start with the one-week Readiness Diagnostic.