Shared Responsibility for AI: What the Cloud Model Gets Right and How to Put It to Work

When an AI system causes harm, the complaint lands on the organization that deployed it. The cause often sits somewhere else: a model update behind an API, an orchestration change that routed requests to a different model, or an agent running on permissions nobody scoped. The party held accountable and the party able to prevent the harm are frequently different organizations.

Cloud security had the same problem, and solved it with the shared responsibility model. AI governance should borrow that model. This post covers what that looks like in practice and where Airia fits.

What the cloud model actually does

The familiar diagram is the least important part. Four mechanisms do the work:

A published split. Providers state which controls they own, which the customer owns, and which are shared.

A boundary that moves with the service model. An IaaS customer owns far more of the stack than a SaaS customer.

Assurance that names the customer’s obligations. A SOC 2 report lists complementary user entity controls: the controls the customer must perform for the provider’s controls to work.

Contracts for use-dependent obligations. The provider doesn’t know what data you store, so regulated uses are handled through agreements like a HIPAA business associate agreement.

The same split applies to AI

The service models translate directly:

Self-hosted open weights are the IaaS analog. You inherit safety filtering, evaluation, patching, logging, and change control.

A model accessed through an API is closer to PaaS. The provider handles model security and safety layers. You own the use, the data you send, and the oversight around outputs.

An AI application or agent platform is the SaaS analog. The vendor owns more, but you still own what the system is used for and how much people rely on it.

One thing never moves: the use case. No vendor knows what decision your system feeds, who it affects, or how much weight your people put on its output. That’s why the use case is the right unit of governance, and why it always sits in the deployer’s column.

Where deployers get stuck

Three gaps show up again and again:

No written split. Providers publish usage policies and model cards, but rarely a control-by-control statement of what they own and what you own.

Unstated assumptions. A provider’s safety and evaluation claims assume things about how the model will be used and overseen. Those assumptions are almost never written down.

Silent change. Models, routing, and tools change after approval, and nothing requires anyone to tell the deployer.

How Airia helps

Airia is built around the deployer’s column: the part of the split that stays with you regardless of which models or vendors you use.

The use case is the unit of record. Every AI use case moves through a defined lifecycle: register, assess, mitigate, approve, and monitor. Registration captures the decision the system supports, the affected population, and the reliance relationship. Those facts drive risk tier and required controls, rather than the name of the model underneath.

Risk is scored before and after controls. Inherent and residual risk are tracked separately, so you can see which controls are carrying the risk down. You can also see when a change upstream means they’ve stopped doing so.

Airia is explicit about which controls it can enforce. Airia can enforce a control only where it manages the configuration or sits in the path of the traffic. The platform distinguishes those controls from the ones your team has to perform. That’s the complementary-controls idea applied to Airia itself. You see which mitigations the platform handles and which remain yours.

Obligations map to frameworks. Use cases and controls map to the EU AI Act, ISO 42001, NIST AI RMF, and state laws such as Colorado’s. When an obligation depends on how a system is used, the mapping reflects that use.

Monitoring runs against the use case. Post-deployment monitoring asks whether the system still fits the use case you approved, not just whether generic metrics look healthy. A change in model, routing, or scope becomes a governance event, not a surprise.

Disclosures stay current. Airia’s Living Disclosures keep transparency outputs tied to the governance record, so what you tell regulators and affected people reflects the system as it runs today. These outputs include internal dashboards, external trust notices, and framework adherence views.

Questions to bring to your next vendor review

Has this vendor said, in writing, which controls it owns and which we own?
What do its assurances assume we’re doing, and are we doing it?
Who tells us when the model, routing, or tooling changes, and how quickly?
Which service model are we actually consuming?
Is our use case classification documented, and does it sit clearly with us?

The gap between where harm lands and who controls the system isn’t going away. Cloud showed that you don’t have to close the gap to govern it. You have to write it down and keep the written version current. That’s the work Airia is built to support.