AI System Governance and Compliance
SOC2 is a control framework that is audited annually, and customers rely on it when winning enterprise contracts.
A Question That Comes Before the Contract Closes
Imagine an enterprise customer is ready to sign a contract for an AI system. Just before the deal closes, a question comes up that has little to do with how good the model is and much more to do with trust: does the system meet the compliance standards the customer already depends on? For many enterprise customers, one of those standards is SOC2. This article looks at what SOC2 asks of an AI deployment, and why the engineer deploying the system has to think about it from the very start rather than after the system is built.
What do you think happens?
Before reading on, decide: when a customer asks whether an AI system meets SOC2, what is the main thing they are checking?
Reveal answer
Whether the customer's own operations are controlled and can be shown to be controlled
The source frames the SOC2 question as one of trust rather than model quality. SOC2 is part of how the customer demonstrates to its own buyers that its operations are controlled, and that is why it reaches into the systems the customer runs, including AI systems.
What SOC2 Is and Why Its Audit Matters
SOC2 is a control framework that is audited annually, and customers rely on it when winning enterprise contracts.
A control framework is a set of controls, which are the concrete practices an organization operates and can be checked against. SOC2 is audited once a year. The audit is what gives the framework its weight: the controls are not just claimed, they are examined on a recurring basis.
The source explains why the framework matters commercially. The customer's enterprise sales team relies on SOC2 to win contracts. In other words, SOC2 is not only an internal engineering concern. It is part of how the customer shows its own buyers that its operations are controlled. Because the customer's operations include the AI systems it runs, SOC2 reaches into those systems too. For the AI vendor, this means the deployment is judged not only on what it does but on whether it fits inside the controls the customer must demonstrate.
Where the AI System Sits Relative to the Perimeter
The central condition in the source is a question of location within a boundary. The perimeter is the boundary that determines which systems fall under the customer's SOC2 obligations. If the AI system runs inside the customer's SOC2 perimeter, the SOC2 controls apply to that system. The source does not spell out in detail how that boundary is drawn, so the practical first step is to find out where the customer's perimeter ends and where the AI system sits relative to it.
Once the system is known to be inside the perimeter, the source names four controls that apply to it: change management, access management, vulnerability management, and incident response. These four sit underneath the SOC2 framework as the concrete areas the audit looks at. The diagram below shows the arrangement: the framework covers systems within the perimeter, and the four controls are the areas that apply to those systems.
Working Through Whether the Controls Apply
Deciding scope for a customer's AI feature
A customer runs an AI assistant that its own staff use on internal records, and that assistant is deployed within the customer's SOC2 perimeter. Which of the source's four controls apply, and what does the FDE do first?
- 1Locate the perimeter
The first question is location. The FDE determines where the customer's SOC2 perimeter ends, because that boundary decides which systems fall under the customer's SOC2 obligations.
- 2Place the system relative to the boundary
The assistant runs inside the perimeter, so the source's condition is met. The SOC2 controls apply to this system.
- 3Name the applicable controls
The four controls the source names for a system inside the perimeter all apply: change management, access management, vulnerability management, and incident response.
- 4Keep the scope question separate from the design question
Knowing that the four controls apply is only the first responsibility. The FDE still has to design the assistant so the evidence an audit will request can be produced.
Because the assistant sits inside the customer's SOC2 perimeter, all four named controls apply to it, and the FDE's scoping work starts from that location check.
Tracing How Audit Evidence Reaches the Auditor
The second FDE responsibility is about engineering. The source says the FDE must design the system so the evidence the audit will demand can actually be produced. Evidence is not something you assemble after the audit is announced. It has to come from the running system, which means the system must generate and keep the records the auditor will need. The source's second responsibility is the question of whether those records exist.
Follow the path in the diagram below. The AI system is in operation. Along the way, the system produces operational records, such as logs, access records, and change history. Those records have to be captured and kept so that they can be turned into evidence. When the auditor asks for proof that the controls operated, that evidence is what gets handed over. If the system never captured a record along the way, there is nothing to hand over later.
Comparing the Two FDE Responsibilities
The source gives the FDE two responsibilities that run in sequence. They look similar because both serve the audit, but they answer different questions. The first is about scope and the second is about design. Keeping them apart helps avoid the mistake of treating SOC2 as something to think about only after the system is built.
| Aspect | Knowing which controls apply | Designing for evidence |
|---|---|---|
| Question answered | Which of the four controls cover this deployment? | Does the system generate and keep the records the auditor will need? |
| Nature of the work | A question of scope | A question of engineering |
| Position in the sequence | First | Second, after scope is known |
| What it depends on | Where the AI system sits relative to the customer's SOC2 perimeter | What the audit will demand, and what the running system actually records |
| Effect on the audit outcome | Defines which controls must be shown to operate | Determines whether the required proof can be produced at all |
The two responsibilities the source assigns to the FDE for SOC2
Mistakes Engineers Make With SOC2 Scope
Common mistake Treating SOC2 as a concern that only arrives after the system is built
Why it failsThe source says the engineer has to think about SOC2 from the very start, because the evidence has to be designed for before it can be produced.
Do this insteadAsk the location question and the evidence question during design.
Common mistake Assuming the model's quality answers the compliance question
Why it failsThe source frames the compliance question as one of trust rather than model quality.
Do this insteadTreat SOC2 as a separate requirement that the deployment must satisfy alongside model performance.
Common mistake Skipping the perimeter check and assuming all four controls always apply
Why it failsThe source's central condition is whether the AI system runs inside the customer's SOC2 perimeter. The controls apply to that case.
Do this insteadFind where the perimeter ends and where the system sits before deciding which controls are in scope.
Common mistake Assuming evidence can be gathered from memory after an audit is requested
Why it failsThe source says the system itself must be designed so the evidence can be produced.
Do this insteadMake sure the system captures the records the auditor will need while it runs.
Applying the Two Responsibilities to a New Deployment
A customer is deciding whether to deploy an AI system that its own staff will run inside the customer's SOC2 perimeter. Describe, in order, the two things the FDE must do for SOC2 on this deployment, and say what each one produces.
Hints
- Start with the location question: where does the perimeter end relative to the system?
- The first responsibility establishes which of the four named controls apply.
- The second responsibility concerns whether the running system generates and keeps the records the audit will request.
Key Takeaways
- SOC2 is a control framework that is audited annually, and customers rely on it when winning enterprise contracts, so it bears on the trust a deployment must earn.
- When an AI system runs inside the customer's SOC2 perimeter, the four named controls apply: change management, access management, vulnerability management, and incident response.
- The FDE's first responsibility is scope: knowing which controls apply, which depends on where the system sits relative to the perimeter.
- The FDE's second responsibility is design: building the system so the evidence the audit will demand can actually be produced from the running system.
- Both responsibilities should be addressed during design, not after the system is built.