Access Control for AI Systems. What SOC 2 and the EU AI Act Actually Require.

Why AI Access Control Is Different

Access control is not a new compliance concept. Every security framework from SOC 2 to ISO 27001 addresses who can access what systems and data.

What is new is the specific access control requirements that apply to AI systems - and the ways most teams are failing to meet them.

The SOC 2 Requirements

SOC 2 Trust Services Criteria CC6.1 requires that logical access security software, infrastructure, and architectures are implemented to support the achievement of commitments and system requirements.

For AI systems this translates to specific obligations that most teams have not fully addressed.

Model access controls. Who can query production models. Who can modify model weights. Who can access training data. These access paths need to be documented, controlled, and logged.

Training data access. The data used to train your models is typically among the most sensitive assets in your organisation. SOC 2 requires logical access controls that restrict access to authorised users and processes.

Audit logging. CC7.2 requires that system components are monitored to detect and assess anomalies. For AI systems this means logging model inputs and outputs, access events, and configuration changes in a tamper-evident format.

Incident response. CC7.3 requires documented procedures for responding to security incidents. Most AI teams have general incident response plans that do not address AI-specific scenarios such as model poisoning, adversarial inputs, or unexpected model behaviour.

What the EU AI Act Adds

The EU AI Act introduces additional access control requirements for high-risk AI systems.

Article 12 requires that high-risk AI systems be designed to enable logging of events throughout the system lifecycle. These logs must be retained for a period appropriate to the intended purpose.

Article 17 requires that providers of high-risk AI systems establish a quality management system that includes documented procedures for access control and change management.

The Gap We See Consistently

The most common access control failure in our diagnostics is not that teams have no controls. It is that the controls they have were designed for traditional software systems and have not been extended to cover AI-specific access patterns.

A typical example: an organisation has strong access controls on their application infrastructure. But their ML engineers have broad access to production model weights, training data, and inference endpoints without the same level of control, logging, and review that applies to their application code.

This creates a compliance gap that is not visible in a standard SOC 2 assessment but would be surfaced in an AI-specific audit.

The Minimum Viable Access Control Framework for AI

Based on SOC 2 and EU AI Act requirements the minimum viable access control framework for an AI system includes:

A documented access control policy that explicitly covers AI assets including models, training data, inference endpoints, and configuration systems.

Role-based access controls with least privilege applied to all AI assets. Engineers should have access to what they need for their role - not broad access to all production AI infrastructure.

Immutable audit logging for all access to production models and training data. Logs should capture who accessed what, when, and what actions were taken.

A documented incident response procedure that covers AI-specific scenarios including model compromise, data poisoning, and adversarial attack.

Quarterly access review to ensure that access rights remain appropriate as team composition and roles change.

None of these requirements are technically complex to implement. The gap is almost always documentation and process rather than technical capability.