Buyer questions
Questions heard in enterprise AI procurement calls and architecture reviews, with the capability each question tests.
These questions come from procurement calls and architecture reviews. The wording stays close to the original conversations.
Each question maps to the BROCS capabilities it tests and includes the evidence a useful answer should provide. The answers do not recommend products.
Control appears often because buyers need to know whether they can change a system, produce evidence, or stop an action.
Your cloud is down, or at least your region. Can you build and run somewhere else? How long does that switch take?
What it is really asking. Whether a tested second placement exists and the recovery time has been measured.
Ask for a second placement that exists today, an executed runbook, and a recovery time measured in a drill. State usually dominates the switch: database placement, replica currency, and vector-index rebuild time. An unmeasured index rebuild leaves the recovery time unknown.
Can you guarantee our data and code never leave the perimeter? Then how does anyone work remotely?
What it is really asking. Whether remote access is understood as moving the work to the person or moving the data to the person.
Those two requirements only conflict if the work happens on the endpoint. The resolution is to move the workspace rather than the data: the editor, the terminal, and the agent run inside the boundary, and what crosses the wire is pixels and keystrokes. The laptop becomes a viewport. Then "never leaves the perimeter" is an architectural fact you can demonstrate rather than a policy people have to obey, and the answer to a lost laptop is to revoke a session instead of opening an incident.
How do you track what consultants are accessing while they are in your network?
What it is really asking. Whether external people have their own identities, time-bound access, and a per-person record, or a shared credential and a VPN.
The shape that works is federation rather than accounts: the consultant authenticates against their own employer's identity provider, your ingress maps that to a scoped role, and the grant carries an expiry that matches the statement of work. Every request is then attributable to a named person without your directory ever holding them. The failure shape is a shared credential in an email, which produces access records that say "the contractor account" and outlive the engagement by years. If you cannot answer "which consultant opened that record on the 14th", you do not have oversight, you have a network.
Can you provide tooling beyond a terminal server, an SSH session, or a VPN?
What it is really asking. Whether the sanctioned remote path is good enough that people use it, or bad enough that they route around it.
This is a usability question with a security consequence. A remote path that is slower and worse than working locally loses, and the way it loses is that people copy the repository to the laptop "just for today". So the bar is a full working environment: the editor people already use, a real terminal, the agent tooling, the data connections, and enough responsiveness that nobody notices where it runs. If the only options are a jump box and a VPN, expect the data to be on the endpoint regardless of what the policy says.
What are your agents up to? What can they do and touch? How do you know they are doing what they are supposed to?
What it is really asking. Whether anyone has written down the blast radius, and whether there is a record good enough to answer the third part after the fact.
Three artifacts answer this and most organizations have none of them. A permissions document per agent, listing tools with the operations each permits, the identity it acts as, what it can read, where it can send bytes, and what it can spend. A trace per run, recording every tool call with its arguments and the identity it was made under. And a sampled review after the fact, because approval-before-action gets clicked through within a week while nobody ever reads what actually happened.
Agents / Traces / Governance
How do we know someone in accounting is not using the company assistant to write their novel?
What it is really asking. Whether inference is attributed per user and per application at all. The novel is rarely the actual concern.
You know the same way you know anything else about usage: every inference call carries an application, a team, and a user, because it went through a gateway rather than a distributed provider key. Then unusual patterns are visible without anyone reading prompts, which matters because reading prompts to enforce acceptable use is both invasive and unreliable. Worth being honest about the ranking, though: personal use is a policy annoyance, while the same missing attribution also means you cannot answer what anything costs, who caused a spike, or which team is actually getting value. Fix the attribution and the novel takes care of itself.
Are people feeding corporate data, IP, PII, or PHI into hyperscaler model endpoints without a BAA or approval?
What it is really asking. Whether endpoint eligibility is enforced by a system or documented in a policy.
Assume yes until something enforces otherwise, because the sanctioned path is usually slower than the browser tab. The enforceable version has two halves. Eligibility is data: which endpoints are covered by which agreement is recorded somewhere the routing layer reads, so a request tagged as containing protected data can only reach a covered endpoint. And discovery is separate work, because the traffic you most need to find is the traffic that never went through your gateway. Start with expense reports and the OAuth grant list in your identity provider; both are faster than network telemetry and usually more revealing.
How do I provide consistent tooling and runtime across every cloud and the local datacentre?
What it is really asking. Whether the platform abstracts the deployment unit and the model endpoint, or tries to abstract whole clouds.
The hybrid cloud lesson applies directly: abstract the workload and the small set of interfaces it depends on, not the infrastructure. In practice that means a containerised deployment unit, a model endpoint that is a capability rather than a provider name, object storage and SQL rather than proprietary equivalents, one federated identity provider, and a data plane that keeps serving when the central control plane is unreachable. Get those five right and placement becomes a configuration value. Get them wrong and every environment is a fork.
How do I let people do remote work without taking data or code with them?
What it is really asking. Whether there is a zero-footprint path, and whether it is pleasant enough to be the default rather than the exception.
Put the workspace inside the boundary and give the person a session, not a copy. Nothing syncs, nothing clones, and the controls that matter are the boring ones: clipboard and file-transfer policy on the session, egress restrictions from the workspace, and an idle timeout. An engineer should choose this path on a normal Tuesday, because an avoided zero-footprint path produces a footprint anyway.
What happens when someone crosses a border with a laptop and still needs access?
What it is really asking. Whether the laptop holds anything worth seizing, and whether access can be scoped by where the person currently is.
Two separate problems, and conflating them is why this usually goes badly. The device problem is solved by the laptop holding nothing: if the workspace lives inside the boundary, an inspected or seized machine yields a browser and a revoked session. The access problem is that the same person, in a different country, may be subject to different rules about what they can reach, which means location has to be an input to authorization rather than a property of the network they dialled in from. Both are worth deciding before the trip, because the alternative is a policy written at an airport.
How do we govern cross-border data access when the person is in one jurisdiction and the data is in another?
What it is really asking. Whether residency is enforced at the point of processing or asserted in a diagram.
Split the question in two, because the answers are different. Where the data is processed is a placement decision and it has to be enforced by the runtime and the routing layer: a request tagged for one region must not be served by a model or a workspace in another, and that is a control rather than a convention. Who may reach it is an authorization decision that has to take the person's current location as an input. The record that ties them together is the access log plus the trace, which is also exactly what a regulator asks for, so building it once serves both purposes.
How do we actually facilitate data sovereignty rather than promise it?
What it is really asking. Whether the sovereign paths are live options or roadmap items.
Sovereignty is demonstrable or it is marketing. The demonstration has three parts. Inference happens somewhere you control, which means at least one of a local model, a model served through your own cloud account, or a contractually covered endpoint is running today rather than planned. Placement is a property of a workload rather than of an installation, so a new jurisdiction is a configuration change instead of a parallel platform. And the deployed system keeps working when the central control plane is unreachable, because a dependency on someone else's control plane is a dependency on someone else's jurisdiction.
What stops one of our own people from using the assistant to walk half the customer database out the door, politely, one question at a time?
What it is really asking. Whether the assistant inherits the caller's entitlements or connects to data with its own privileged credential. If it runs as a service account with broad read access, it is an entitlement bypass with a chat interface. Also whether anyone watches aggregate patterns, because this insider looks like thousands of small authorized queries, not one big theft.
Queries should run under the caller's identity and row-level entitlements. Per-user quotas and aggregate monitoring should flag patterns such as an analyst retrieving 40,000 customer records through individually authorized queries. Files, summaries, and pasted output should use the existing loss-prevention path. The supplier should identify the exact permission context used for each query; a shared privileged connector creates an entitlement bypass.
If someone hides instructions in a document or an email and our agent reads it, what stops the agent from doing what the document says instead of what we said?
What it is really asking. Whether the vendor treats everything the agent reads as attack surface, or trusts the model to tell instructions from data. The mature answer is architectural: least-privilege tools, egress control, and human gates that hold even when the model is successfully fooled. The immature answer is confidence in the model's training.
Assume that retrieved-content injection can succeed. Scope each tool to the minimum required permissions, constrain outbound egress, and require a separate approval for irreversible actions. Traces should show unusual tool and data-access patterns. Model training is one defense and cannot replace these system controls.
What do you keep of what we send you, for how long, and does any of it end up training your models?
What it is really asking. Whether the data path to every model in the stack is known and contractually pinned, or assumed. Retention and training terms differ per provider, per tier, and sometimes per endpoint, and "we don't train on your data" is often a setting someone had to turn on, not a default.
Require an inventory for every model behind the platform: retained prompts, outputs, embeddings, and logs; retention period; physical location; and the governing contract, BAA, or DPA. Separate platform audit logs from provider retention and include abuse-monitoring buffers, support access, and telemetry. One provider's marketing page does not document a routed multi-model stack.
An agent did something wrong at 2am. Who gets paged, what do we shut off, and what do we show the regulator afterwards?
What it is really asking. Whether AI systems live inside the existing incident machinery or outside it: a named owner on a rotation rather than "the AI team", severity definitions that treat unavailable, degraded quality, and did-something-it-shouldn't as three distinct failures, a kill switch that stops one agent without taking down everything, and a record complete enough to reconstruct what the agent saw, decided, and touched.
Put the agent in the existing paging and ticketing systems with an owner, severity model, and SLO before launch. Exercise per-agent stop, revoke, and quarantine actions in a drill. The incident trace should record the input, decision, tool calls, data touched, model version, and prompt version. An integration-wide shutdown gives one agent a platform-wide blast radius.
What does this actually cost at full rollout, and can we put a hard cap on it? I'm not signing up for a bill that scales with employee enthusiasm.
What it is really asking. Whether consumption is a measured, attributable, capped quantity or a monthly surprise. Per-seat pricing may exclude inference; two hundred apps hammering one shared org-level key is the other, because the batch job and the customer-facing app starve each other in the same peak hour.
Require a defined metered unit and attribution by user, team, and application. A cap must throttle, switch models, or block requests when the budget is crossed. The same metering point can enforce workload priorities during contention. Include step costs such as index rebuilds and fine-tuning runs. A full-rollout estimate needs the prior month's cost by team.
Our SOC 2 audit now has AI in scope. What evidence can you actually hand my auditor, and is any of it going to be screenshots?
What it is really asking. Whether the controls produce evidence as a by-product of operating, or whether audit season means three weeks of manual assembly. Also whether the platform's attestations compose with yours: the auditor will ask who can reach which models, who changed the prompts, and who reviewed the agents' permissions, and those answers need artifacts.
Map each AI-specific control to continuous evidence: access reviews for models and data, approved change records for prompts and agent configuration, policy-enforcement logs, and the platform's own attestation. Evidence should be exportable for a defined date range. A certification page alone leaves the organization assembling its AI audit record from tickets and memory.
Can this run with the cable unplugged, no internet at all? And when the answer is yes, how do model updates get in?
What it is really asking. Whether on-prem means disconnected or merely nearby. Many air-gap claims still phone home for license checks, telemetry, container pulls, or the model API itself, and each of those is a wire across the gap. The update question is the honesty check: a real air gap makes updating models and software genuinely hard, and a vendor who says it is easy has not done it.
List every outbound dependency and demonstrate its offline replacement: local licensing, disabled telemetry, an internal registry for images and model weights, and models that run inside the boundary. Document signed transfer bundles, approved media, verification on arrival, update cadence, and rollback. State which features require connectivity. An install guide that pulls from a public registry fails the air-gap requirement.
If this doesn't work out, how do we get the documents, prompts, fine-tunes, embeddings, and logs out? If you get bought or go under, can we keep running without you?
What it is really asking. Whether the exit path includes source data, derived artifacts, and operating records, and whether the system can continue if the supplier ceases operation.
Start with an inventory of source data, prompts, workflow definitions, fine-tuned weights, vector indexes, and audit logs. For each item, state its export format, cost, delivery time, and the last successful export test. Continuity is stronger when the software runs in the customer's tenancy under a perpetual license to the deployed version. Escrow helps when deposits are current and an independent party has built from them. An API-only export may require rebuilding derived state. That work determines the switching cost at renewal.
The provider updated the model under us and quality dropped over the weekend. How would we even know? And when they deprecate it outright, how bad is the migration?
What it is really asking. Whether a third-party model is treated as a dependency you manage or as weather. Pinned versions, a baseline eval that catches silent swaps, notice periods in the contract rather than a changelog policy, and workflows that call an abstraction instead of a model directly, so substitution is a measured diff and not a rewrite on someone else's deadline.
Pin model versions everywhere the provider allows it; where they don't, that is a risk accepted in writing. Run a scheduled eval against a golden set of real cases so a silent change shows up as a metric diff within hours, with an alert, not as a slow bleed of user trust. Any model change, planned or not, gets a change record, an eval comparison, and a go or no-go like every other dependency upgrade, and one approved alternative stays warm per critical app so "roll back the model" is an actual option. Self-hosted open weights are the strong form of the answer, since deprecation becomes your decision on your schedule. A vendor who says "the new model is better" has answered a different question than the one asked.
Ask a better one
If you have a question this list does not answer, or an answer here is wrong in the field, open an issue on the BROCS repository. Questions that keep coming up in real rooms are worth more than questions that sound good in a framework.