The premise
An AI audit is a structured assessment of every AI integration a business is running (what is deployed, where it is load-bearing, what data it touches, where it is leaking trust) that produces a ranked remediation backlog and a build-or-buy verdict for each item. It is the work that turns an accidental AI stack into a deliberate one.
Most operating businesses we audit in 2026 are running between three and twelve AI integrations: a copilot in the email client, a meeting-summary tool, a vendor-supplied scoring agent, a customer-support assistant, a homemade ChatGPT workflow that one team uses, and somewhere in the stack a vendor agent that nobody can explain. None of it was chosen against a strategy. All of it costs money. Some of it touches customer data. Almost none of it has been tested against a measurable outcome.
Founders and CEOs come to SDEN with a version of the same question: where do we actually stand on AI, and what should we do next? An audit answers it. This piece is the playbook: what we assess, in what order, what the deliverables look like, and the failure modes we see most often. Read it before you write the next AI cheque.
The AI stack you have is not the AI stack you chose
Most businesses' AI footprint accreted by accident, one trial subscription at a time.
Three years into the generative-AI cycle, the buyer side has changed shape. The 2023 conversation was about whether to start. The 2024 conversation was about which model. The 2025 conversation was about agents. The 2026 conversation is the one nobody planned: there are already too many AI things running, the bill is not small, and nobody in the building can produce a list of what is deployed without opening five admin consoles.
We have not yet audited a company under 200 employees that knew, off the top of its head, every AI integration touching customer data. The most common surprise is a sales-tools-vendor that uses customer email content to train a shared model, buried in a clause the legal team did not flag at signature. The second most common is an internal ChatGPT workflow that one team built with paid accounts, pasted customer PII into for six months, and never told the CTO.
An audit is not punitive. It is the first time anyone in the company looks at the AI footprint as a portfolio. Done well, it produces three pages a CEO can take to a board meeting and one document the engineering team can ship from.
The five dimensions, in order
An AI audit is not a security review. It is broader, and the security review is one slice of it.
We assess each AI integration against five dimensions, in this order. First, inventory: what is deployed, by whom, under what contract, billed to what cost center. Second, data exposure: which fields cross the boundary, whether the vendor contractually excludes training, where the data lands geographically. Third, criticality: is the integration a convenience or is it on a critical path, i.e. would the business notice within a day if it stopped working. Fourth, evaluation: is the output measured against any baseline, by anyone, at any cadence. Fifth, ownership: who maintains the prompt, the configuration, the eval set, the cost ceiling, and what happens when that person leaves.
The order is deliberate. Inventory before data exposure, because you cannot audit what you cannot list. Data exposure before criticality, because some integrations need to be turned off the day the audit closes regardless of how critical they have become. Criticality before evaluation, because the integrations that nobody is measuring are usually the ones that have quietly become most load-bearing. Evaluation before ownership, because an unowned integration with a working eval is recoverable, and an owned integration with no eval is not.
Each dimension produces concrete artifacts: an inventory CSV with every integration, a data-flow diagram for every integration that touches customer data, a criticality matrix, an evaluation gap analysis, and an ownership register. None of this is novel; it is the basic discipline applied to a category of software that has been allowed to skip it.
Three documents, one backlog, one decision per item
An SDEN AI audit produces three documents and one engineering artifact. The first document is the inventory, ranked. The second is the risk register: every integration mapped against the OWASP LLM Top 10 (prompt injection, training-data leakage, model denial of service, supply chain, sensitive information disclosure, insecure output handling, excessive agency, overreliance, model theft, vector and embedding weaknesses) plus the data-exposure assessment. The third is the build-or-buy memo: for each integration, an explicit recommendation, whether to keep, replace with a different vendor, replace with custom, or deprecate.
The engineering artifact is a ranked remediation backlog written as shippable issues, with severity, effort, and owner suggested. The backlog is not a wishlist; it is the engineering team's next two months of AI work, in priority order. We deliberately rank by exploitability and business impact, not by how easy the fix is. Easy fixes are still useful, but ranking them ahead of harder critical ones is how organizations end up with hardened side doors and a front door propped open.
Three pages and one backlog is the bar. Anything longer is a consulting report: useful to the auditor, useless to the team that has to act on it. An audit that does not land in your issue tracker the day it closes is an audit you paid for and did not buy.
What an audit changes in the week it lands
Four shifts we have seen inside operating businesses immediately after closing an AI audit. None of them are speculative; each describes a change that landed within seven days of the report.
The CEO believes the company is running 'a couple of' AI tools. The CFO sees a recurring spend line called 'software, other' that has tripled in nine months and cannot be broken down.
The inventory page lists 11 active AI integrations with monthly cost, owner, and data-exposure flag. The CFO ties every line to a contract; three subscriptions get cancelled in the first week, overlapping with tools the team forgot about.
Takeaway · Visibility precedes everything. You cannot govern what you cannot enumerate.
A sales-tools vendor processes inbound email content through a shared model. The legal team has not read the latest TOS update; the privacy policy on the website does not disclose it.
Data-exposure flag triggers a contract amendment request and an interim policy update. The integration is either renegotiated to an enterprise tier that contractually excludes training, or replaced. The privacy policy is fixed before any regulator notices.
Takeaway · AI data-flow review is now part of vendor onboarding, not an annual surprise.
An internal ChatGPT workflow that one team built handles a meaningful slice of customer support drafts. Nobody owns the prompt; nobody has measured the quality; the team that built it has rotated.
The workflow either gets a measured baseline and an owner, or it gets deprecated. Decision made in the audit close meeting, not deferred.
Takeaway · Unowned AI is the same risk class as unowned production code. The audit forces the call.
The board has asked the CEO twice whether the company is 'doing enough on AI'. The CEO does not have a defensible answer beyond a list of vendor logos.
The CEO has three pages: the portfolio, the risk register, and the build-or-buy memo. The board conversation moves from anxiety to decision.
Takeaway · The audit is also a governance artifact. It exists for the board, not just the engineering team.
Three principles that separate an audit from a slide deck
An audit is only useful if it lands as actionable engineering work. The three commitments below are what makes the difference.
Findings ship as issues
Every finding lands in your issue tracker as a fixable ticket with severity, effort, and a reproducer where one applies. We do not deliver an audit as a PDF that nobody opens after week three.
Build-or-buy per integration
Every integration gets an explicit recommendation. We do not produce a generic 'consider building custom'; we say which integrations are right to keep, which to replace, and which to deprecate, with the reasoning.
Re-audit cadence agreed upfront
AI changes faster than the rest of the stack. We agree the next audit date at close, typically six months out, along with the trigger events that bring it forward (new vendor, new use case touching customer data, new regulation).
Six months after the audit
The right test of an audit is what the business looks like two quarters later.
An audit that worked produces three observable changes by month six. The AI inventory is current, maintained by an owner, and reviewed in the monthly engineering ops meeting alongside the security inventory. The remediation backlog is mostly closed: the critical items have shipped, the deferred items have a documented reason for deferral. And the build-or-buy decisions have been honored: vendors that were marked for replacement have either been replaced or formally re-evaluated with an explicit decision to keep them.
What separates the audits that age well from the ones that quietly fade is whether anyone owns the discipline after we leave. The most common failure mode is not technical; it is organizational. The audit closes, the report sits in a folder, the head of engineering rotates, and by quarter three the inventory is out of date again. The counter to that is small and unglamorous: a recurring 30-minute monthly meeting, owned by a named engineer, where the AI inventory is reviewed and the backlog is updated. It does not need to be more than that. It does need to actually happen.
The deeper outcome is that the AI portfolio stops being a source of vague anxiety and starts being a managed surface, like the cloud bill, the security posture, or the dependency graph. That is the win.
AI for founders:
questions we get asked.
Direct answers to the questions we get asked the most. If yours isn't covered, write to the team.