SOC 2 is not a checklist you pass. It is an auditor forming an opinion about whether the controls you say you have are actually operating — which means the evidence, not the intention, is the product.
This is written from having built a multi-tenant AI system to pre-audit standard rather than from summarising the framework. The parts below are the ones that cost the most and get planned for the least.
Isolation is a design decision, not a control you add
The question an auditor keeps returning to is whether one customer can reach another's data. For a multi-tenant AI product this is harder than for a conventional application, because there are more paths.
The obvious one is the database, answered with rules at the row level rather than filters in the application. The less obvious ones: the search index, where one customer's documents can be retrieved into another's answer if the retrieval is not scoped; the cache, where a response keyed carelessly is served to the wrong tenant; and the logs, where support staff routinely see everything because nobody scoped the debugging view.
Every one of those has to be scoped by tenant, and every one has to be demonstrable. Retrofitting this means revisiting every read path in the system, which is why it belongs in the first commit rather than the month before the audit.
Access control has to be evidenced, not asserted
The control is not "we restrict access." It is "we restrict access, here is the list of who has what, here is the record of each grant being approved, and here is the evidence of the quarterly review."
That reframes it as an operational habit rather than a configuration. Joiners, movers and leavers, with a record. Administrative access that is requested and time-limited rather than permanent. The uncomfortable question is not whether your permissions are right today — it is whether you can show they were right in March.
Change management is where AI products struggle
Auditors want to know that changes are reviewed, tested and traceable. Conventional software has this largely solved: version control, pull requests, a pipeline.
AI products have a category of change that usually sits outside all of it — the prompt. Prompts are edited frequently, sometimes through an admin interface, often by someone who is not an engineer, and they change system behaviour materially. If they are not versioned and reviewed like code, there is a change path with no control on it, and an auditor will find it.
The fix is straightforward and needs deciding early: prompts live in version control, changes go through review, and the version is recorded against every output.
Monitoring means alerting, not dashboards
A dashboard nobody watches is not a detective control. What is being asked is whether you would know — about failed logins, unusual access patterns, jobs that stopped running, error rates that moved.
The AI-specific version: would you know if answer quality degraded? A model or prompt change can quietly make outputs worse without producing a single error. That needs an automated evaluation set run on every change, with an alert on regression — which is also, conveniently, just good engineering.
Vendors are in scope
Your model provider, your hosting, your search index, your logging — each is a subprocessor and each is part of your control environment. Auditors ask what diligence you did, what the contracts say, and how you monitor them.
For AI products this bites harder than usual, because the model provider sees your customers' data. Their retention policy, their geography and their sub-processors become facts about your product that you have to be able to state.
The pattern worth taking away
Every item above is cheap at design time and expensive later, and the reason is identical each time: the evidence for a past period cannot be created retrospectively. Either it was captured as it happened, or that period cannot be attested.
That is the whole argument for building the evidence layer first. For regulated and compliance-heavy firms that is our default; if you are already mid-build and want to know what an auditor would find, a Reality Check is one week and a written answer.
This is the part we do — the crossing from a demo to a system that survives production.