Box AI Compliance: Turning Platform-Neutral Model Routing into Evidence

Box describes its AI approach as platform-neutral, currently integrating models from Microsoft Azure, Google and others, with a commitment to always provide information on which models are used. That commitment is the useful starting point for a compliance review, because it converts a routing decision into something a customer can name in an artefact.

What it does not settle is whether sending a particular document to that model was permitted for that user on that date.

TL;DR

• Box integrates third-party models under a platform-neutral approach and commits to publishing which models are used, which makes model destination a recordable field rather than an assumption.
• Box states it will not train AI models on customer content without explicit approval, and that prompt and answer information is deleted from the provider's system once the answer returns.
• Box AI is governed by Box's existing permissions, so users can only reach files they are already authorised to view.
• Box's AI governance program references the NIST AI Risk Management Framework and the OECD AI Principles, with oversight across security, legal, compliance and product.
• The customer still owns the decision about whether a given classification of content may cross the model boundary at all.

What the vendor commitment covers

The Box AI trust material makes three statements a reviewer can test against. Models come from multiple providers under a neutral routing approach, with disclosure of which are in use. Customer content is not used to train models without explicit approval. Prompt and answer information is deleted from the provider's system once the answer returns, and question and answer information is deleted after documents close.

Those are processor-level commitments, and they answer a processor-level question. The ones they leave open are all controller-level: which legal basis covered this processing, which purpose was approved, which data classification was in the document, and who authorised the transaction.

Box's governance program references the NIST AI Risk Management Framework and the OECD AI Principles. Naming a framework in a vendor programme is a signal about internal practice, and it is not a control the customer can evidence. Keep the two in separate columns of the file.

Permission inheritance is an input, not the whole control

Box AI operates under Box's built-in permissions, so a user can only ask about files they already have access to. That inheritance is the correct design, and it produces a specific failure mode: a permissions error in a folder becomes an AI disclosure, because the assistant faithfully surfaces content the user was technically entitled to reach and organisationally should not have.

A review should sample the path rather than assert it. Select a restricted folder and a document inside it. Run the same query as two controlled users with different entitlements. Preserve both answers with their source references, the effective permission state, and the date. Then change one entitlement and repeat.

Our Box AI security material covers the control configuration side. Compliance review asks the adjacent questions: who approved that configuration, when it was last tested, and which artefact proves the result for a named request.

Retention commitments and what a controller must still record

Deletion at the provider covers one risk, which is secondary use of the content by a third party. It leaves the disclosure itself untouched. Personal data that crossed a model boundary was disclosed to a processor at a moment in time, and a controller's records of processing are supposed to reflect that.

For personal information, record the collection purpose and the approved Box AI use case. For confidential engineering or financial material, identify the permitted model boundary and any route restrictions. For regulated content, document product-specific limits and confirm which capabilities are in scope for the applicable programme rather than assuming platform-wide coverage.

I would reject a control description reading "covered by Box's terms" and nothing else. The file needs the specific capability, the site or enterprise instance, the model route in force at the time, the data class, and the policy version. Anything less is a vendor statement wearing a customer's letterhead.

The compliance review versus the security review

A security review asks whether permissions, encryption, and admin controls are configured correctly. A compliance review asks who approved them, when they were tested, and what proves the outcome for a sampled transaction.

The distinction shows up sharply on model routing. Security asks whether the route is to an approved provider. Compliance asks for the record showing which provider received which classification of content on which date, with the approval that authorised it. Box's disclosure commitment makes the first field available. The rest has to be generated inside the deployment.

The AI governance audit framework gives the structure for holding these artefacts together, and the AI vendor risk assessment template covers the procurement boundary where the Box attestations live.

The evidence package for one sampled request

Begin with the originating identity and timestamp. Add the Box instance, the source documents supplied as context, the effective permissions, and the model destination. Preserve the content classification, the policy outcome, the administrative configuration snapshot, and the link to the approved use case.

Add a denied test. Send a controlled payload whose classification is prohibited for the selected route and retain the refusal record. Repeat it after a permission change and after the capability is disabled for a group. Those two tests separate an operating control from a settings page, and they take an afternoon to produce.

Vendor due diligence records belong in the same file with their own owner and review date, kept visibly apart from the operational evidence. Mixing the two is how a file ends up asserting more than it proves.

DeepInspect

DeepInspect provides an independent policy decision at the HTTP AI request boundary. For model traffic deliberately routed through it, DeepInspect evaluates the supplied identity and role against organisational policy for content classification and model authorisation before the request reaches the model.

Each decision produces a signed, tamper-evident record held outside the calling application's write path. That record joins the Box configuration snapshot, the permission test, and the processor commitments into evidence covering one sampled request rather than a general assurance.

Book a technical deep dive at deepinspect.ai.