Enterprise
Every question your security team asks, answered before anyone books a call.
We would rather you evaluated us on a Tuesday afternoon with the door shut than sat through a call to hear it. Written to be forwarded.
- Do you train on our data?
- Where does it actually run?
- What is the agent allowed to do on its own?
- What do we own, and how do we leave?
- Will it connect to what we already run?
- What are you not telling us?
Five questions, and one answer we are not going to fake.
Do you train on our data?
No. Your material trains your system and nothing else, and there is no path by which one client’s data informs another’s. That is an architectural property of how deployments are separated, not a policy we are asking you to trust.
- Training
- Your material trains your system only. Nothing is pooled and nothing crosses between clients.
- Residency
- You choose the region. Where a model provider is involved we name it and say where it runs before anything is sent to it.
- Retention
- Set by your policy rather than ours - including keeping nothing beyond the active conversation.
- Deletion
- On request, and as a documented step at the end of an engagement rather than an assumed one.
- Personal data
- We keep what the process genuinely needs and no more. Where a deployment touches personal data, the lawful basis and the handling are agreed in writing before the build rather than after it.
Where does it actually run?
Usually inside your environment. Most of the time this is decided by your data policy rather than by us, and all three of these are normal.
- Your cloud
- Deployed into your account, under your IAM, watched by your own tooling. The usual choice for regulated work.
- Private / VPC
- Isolated infrastructure, no shared tenancy, network boundaries agreed with your team.
- Managed by us
- We run it and you keep the data controls. The quickest route to a pilot and the easiest to move afterwards.
- Access
- Least privilege by default. We ask for the narrowest scope the integration needs and document what every credential is for.
- Secrets
- Held in your secret manager where you have one. We do not leave long-lived credentials in application configuration.
What is the agent allowed to do on its own?
Exactly what you decide, and the boundary is enforced in the system rather than asked for in a prompt. This is the question that matters most for anything that acts rather than answers.
- Stop conditions
- You define what it must not proceed past. It escalates on those conditions rather than on its own uncertainty.
- Approval
- Any step can require a person before it commits. Which steps those are is configuration, not a rebuild.
- Audit trail
- Every action, its inputs and the reason it was taken are written down and readable afterwards.
- Failure
- When an integration is unavailable the system stops and reports rather than guessing. Silent degradation is the failure mode we design against.
What do we own, and how do we leave?
The build is yours and the exit is planned rather than resisted. Asking this before you start is reasonable, and a vendor who cannot answer it is telling you something.
- The build
- What we build for you belongs to you - the deployment, the configuration and the outputs.
- Documentation
- A written architecture handover, detailed enough that your team can run it without us.
- Lock-in
- No proprietary runtime you cannot operate yourself. Where a third-party model provider is involved we say so, and the integration is replaceable.
- Support
- A support agreement rather than a hostage arrangement. Taking it in-house is a handover we plan with you.
Will it connect to what we already run?
That is the engagement, not a caveat on it. Nothing is migrated and nothing is replaced.
- CRM
- Salesforce, HubSpot, Dynamics.
- Ticketing
- Zendesk, Intercom, and in-house desks.
- Commerce
- Shopify, Wix, and custom catalogs.
- Back office
- ERP, internal APIs, databases and file stores.
- Everything else
- If it has an API or a database we can usually read it. Where it does not, that constraint goes into the scope rather than surfacing halfway through the build.
What are you not telling us?
We are a small team doing enterprise work, and there are things a larger vendor would list here that we will not assert without evidence. If any of these gate your process, ask - you will get a straight answer rather than a logo.
- Certifications
- We will tell you exactly what we hold and what we do not. We would rather lose a deal than imply an audit we have not had.
- Subprocessors
- Named for your deployment specifically, since they depend on the architecture we agree.
- Paperwork
- Send us your DPA, security questionnaire or penetration test requirements and we will work through them.
- Uptime
- Belongs in an agreement for your deployment, not on a marketing page.
Send this to whoever has to sign it off.
If your process needs something this page does not cover, tell us what it is. Better now than at the end of a procurement cycle.